Candidate Review Page approval process issues and open questions

[howard-e]

Vendor approving candidate test plan run

• Currently, admins can also approve. Should there still be an affordance for admins to continue to be able to do this in the case where an "override" is required?
• When an admin views the candidate test plan run page, it also updates the review status to "In Progress". This isn't a genuine update as a vendor's interaction is what should be used to accurately reflect that. The admin causing the status update should be prevented.

Removing vendor's approval

• Currently vendors are unable to "remove their" approval in case they wanted to. Should this even be allowed?
  • NOTE: The following points are moot if the answer to the above question is "No".
  • NOTE2: The above question assumes the parent TestPlanVersion has not yet been promoted to the RECOMMENDED phase.
  • To approve currently, a vendor must move to the last test in the test plan and press the "Finish" button which then provides the 2 options of "Approved" or "Not Yet Approved". The latter will do nothing if the former was selected (and submitted) before.
  • An observation and a question from that:
    • This approach isn't very "intuitive" to get to an approved state. Should a top level interaction be provided to make it easier for the vendor to "sign off" on the review.
    • If approvals can be removed, I would propose for the "Not Yet Approved" option allow for the removal to happen.
    • If approvals cannot be removed, I would propose that the "Finish" button or top level interaction no longer be provided if an approval is already present.

Tracking vendor approvals across TestPlanVersions

• feat: Track vendor approvals across version updates through result copy process #1267 will make it possible for vendor approvals to be "kept" across test plan version updates (in the case where there hasn't been substantive changes)
• Eventually, there will need to be UI to keep track of these approvals in some sort of "timeline". The current data model doesn't make that possible and will eventually need to be extended so to make this content easier (and possible) to track:
  1. When the first version was approved (and by who)
  2. When the latest version was approved (and by who)
  3. If a test in an updated version has to be re-reviewed by vendor(s)
  4. Make vendors easily understand the changes between the versions (will have to rely on git commit messages here)
  5. Follow up proposal on this change in ... (TODO: draft issue outlining data model and process changes)