Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
None
Description of the Change
Add ability to create evidence on reports rather than findings.
Allows users to create evidence not tide to findings and used in the top level of a report template, which is a frequent user request.
This adds a foreign key to the reports on the Evidence model, requiring that either that one is set or the key to a finding is set, but not both. This is enforced with a database CHECK clause.
This also updates the HTML templates and views to support the new evidence functionality. A table of evidence is now shown on the report, with an Add button. The Add Evidence pages and modals now have an extra path parameter to distinguish between the "parent" of the evidence. Report-level evidence is serialized to templates under the
evidence
field at the top level.Alternate Designs
Instead of two foreign keys, one of which can be set at a time, Django's
GenericForeignKey
from thecontenttypes
module could be used. This may be worth pursuing in the future if we want Evidences to be attached to a wider variety of objects, but I decided not to go with something overly generic for now.The "parent type" path parameter to the evidence creation views is a plain string, which isn't restricted at the type level to being either "finding" or "report". A Python Enum would help restrict it a bit more, but Django does not support enum path parameters without additional extensions.
To have "global evidence" without this PR, it may be possible to add a finding whose sole purpose is to hold the "global evidence" and hide that finding in reports, either by name or via a custom field once those are merged. It's awkward, but it's possible without needing new code.
Possible Drawbacks
Extra complexity added to the Evidence model.
Verification Process
I've exercised the UI for creating evidences on findings and reports, as well as cloning reports. I've also extended the test cases to test evidences tied to reports.
Release Notes