Ability to make manual edits to detailed results

[robinbzk]

This is a split issue of now closed https://github.com/internetstandards/Internet.nl-dashboard/issues/202

Background Because of test errors, specific edge cases, and hotfixes, it is often necessary to make manual edits to Excel output of the dashboard in order to reflect the actual status of standards implementation. Since the edits take place outside the dashboard, results and diagrams in the dashboard do not change accordingly. Since we want to be able to share reports straight from and through the dashboard interface (https://github.com/internetstandards/Internet.nl-dashboard/issues/92), the editability of reports becomes a necessity. This also aligns with one of the original goals of the dashboard; to make the manual conversion of API results to presentable form easy.

User story As a dashboard user, I want to be able to make manual edits to detailed results within reports within the dashboard itself, so I don't have to edit Excel sheets anymore to 'clean up' the results and I do not have to make custom diagrams to reflect the changes.

Solution ideas The manual editing of results would require a new view, I can think of the following options:

1. an Excel-like view of the report where you can select valid values per attribute
2. a 'correction wizard' where you first choose the domain(s) you wish to edit, then select the attribute(s) you wish to change, then select the new value(s) from a dropdown menu, then enter a explanation for the change(s), then save the changes.

A 'correction wizard' is more user friendly. It could be behind a simple edit button (example)

Since I think the processing of the statistics is done client side (right?), the diagrams are updated 'automatically' when refreshing the report in the browser. For transparency purposes, a "change log" could be displayed at the bottom of a report (only shown when manual edits were made).

Notes

• There probably needs to be a disclaimer outlining that there could be some interdependencies between results, so the user needs to be sure that all relevant fields are edited. For example: if DMARC existence is set to failed, DMARC policy cannot be passed. It is however too complex to build in all these checks, so a disclaimer should do.
• It is desirable to also be able to change the results link and internet.nl percentage.
• Simply retesting a batch of domains and updating the results of those domains automatically might seem like a solution, however practice shows that test errors could even cause results to regress just minutes or hours between tests. Manual checks and edits ensure that all parties can agree on the results.
• Probably there should be another disclaimer explaining that any wrongful edits will harm the integrity of the report, and a change log of edits is shown for transparency purposes.

[stitch]

Duplicate of #278 ?

[robinbzk]

Duplicate of #278 ?

It's not a duplicate. But the question remains whether it would be desirable to implement such a feature. There are some edge cases where one would like to make manual edits, because Internet.nl tests things that don't need to be tested. With a good implementation of certain standards, Internet.nl would skip the tests.

An example is https://internet.nl/mail/mijn.belastingdienst.nl/597344/ which doesn't have a DKIM key. An spf -all record in combination with DMARC reject policy would render the DKIM test not applicable. But instead, mijn.belastingdienst.nl has an alternative SPF record which also doesn't actually authorize any servers to send mail: v=spf1 exists:_i.%{i}._h.%{h}._o.%{o}._spf.belastingdienst.nl –all (https://www.belastingdienst.nl/wps/wcm/connect/bldcontenten/standaard_functies/individuals/contact/information-for-mail-server-managers/)

Another example is https://internet.nl/mail/werk.nl/597345/#control-panel-2 which has misconfigured its Null MX record. Because of this, STARTTLS and DANE tests are performed, but fail because there is no mailserver to test.

I would like to be able to manually render these failing tests "not applicable", because the non-compliance here shouldn't pose security risks.

But the alternative reasoning would be that werk.nl should just fix their Null MX record, and that leaves the mijn.belastingdienst.nl edge case. Which probably isn't worth changing the dashboard for.