Refactor the security reports naming

Problem to solve

The naming convention behind issues in security reports is confusing. In the store, we have these three issue types, newIssues, resolvedIssues, and allIssues.

They map like this:

  • newIssues: Issues you introduced
  • resolvedIssues: Issues you fixed
  • allIssues: Issues that existed previously, that you didn’t fix

The first problem is that allIssues isn't all the issues, it would be better described as unresolvedIssues, maybe. The problem then is in the next part, component props.

In the component(s), we have 4 different issue types, unresolvedIssues, resolvedIssues, allIssues, and a special type, neutralIssues. They generally map like this to the store:

  • unresolvedIssues => newIssues
  • resolvedIssues => resolvedIssues
  • allIssues => allIssues
  • neutralIssues => resolvedIssues (in special cases)

So renaming allIssues to unresolvedIssues would cause even more problems.

Proposal

When chatting to @filipa about this on slack she gave me the following explanation (parsed from #3995 (closed)):

  • newIssues: items not present in base report but present in head report
  • resolvedIssues: items present in base report but not present in head report
  • allIssues: items present in base report + items present in head report
  • hiddenIssues: items present in both base report and head report

I propose we rename the items in the store to match these descriptions. Then we rename the props in the component to map 1-1 with this naming convention. hidden

I made a snippet that explains how each one works a little better than I can with words.

Edited by Sam Beckham