equal-access
equal-access copied to clipboard
Checker: Interaction between multi-scan and changing rule set #3287
Describe what needs to be accomplished
When a user changes the rule set or deployment in the middle of storing scans, they currently get a report that lists only the final rule set/deployment date, and does not indicate that earlier scans were made with different options. This is inaccurate.
Why does this need to be accomplished
The multi-scan report should accurately reflect the scans that were done.
Related issues or references
This cropped up when working on #3217, when it became unnecessary to close and reopen dev tools after changing the options. Now users can change the options mid-stream very smoothly. The question is whether their stored scans should be cleared or the report should be amended to reflect that scans may be done with different rule sets. Clearing stored scans could be annoying if users want to compare their results for different rule sets.
Triage: All that we need to do to fix this is to add which ruleset was used with which stored scan.
Should probably just disable the ability to change rulesets while scan storing is active.
Can we pop a modal to warn that we'll clear your stored scans if you change archive / guidlines?
Basically if a user has ANY stored scans put up modal (as designed).
- if user chooses cancel the rule set is not changed and stored scans remain
- if user chooses "Change deployment dates" then the stored scans will be deleted if the deployment date changed.
Underlying data changed, i.e., ability to get whether stored scans exist (in Options) and the ability to clear stored scans (in Options) has been done. This was difficult in that Options was outside the extension browser tab structure.
Next I will put the logic in to put up a modal if stored scans exist. The user will then either cancel (i.e., not change the ruleset deployment date or guidelines) or they will choose change whereby we will delete the stored scans followed by performing the ruleset change.
Done just a bit of cleanup and dev test before handing over to QA.
This needs a little more work https://github.com/IBMa/equal-access/issues/1599 @drjoho please review
If cancel need to set the change in deployment date or guidelines back to the active ones.
@ErickRenteria All works. You thought there was a problem with the numbering of the scan labels, i.e., scan_1, scan_2, etc. However, they were designed to run continuously incrementally due to the fact that the user can delete scans anywhere. I can show you if needed. This is the second or third time we have revisited this issue. The numbers have no meaning. The label is just there if the user wants to name the scan something meaningful. So I am done and the PR is ready.
I left it for you to close if you have any questions let me know.