Introduce the dedicated "resolved" state for Vulnerabilities
Problem to solve
Initially, the Vulnerability object was introduced as having open and closed states similarly to other Issuables
. However, some potential drawbacks of this approach were pointed out. Also, from the UX perspective, Vulnerability was re-iterated to have open
/resolved
/closed
state model thus making it different from other Issuables
.
The current implementation of the Vulnerability#state
and Vulnerabilities::Occurrence#state
is based on open
/closed
model and the presence of the dismissal Vulnerabilities::Feedback
for a Vulnerabilities::Occurrence
to determine the dismissal of a Finding.
Proposal
The current implementation has to be changed:
- Vulnerabilities receive a new
resolved
state, all API and service layer code that deals with the resolution of the Vulnerabilities is updated to support that - Vulnerability Findings will have their
resolved
state based exclusively on the parent Vulnerabilityresolved
status - Vulnerability Findings will have their
dismissed
state based on dismissal Feedback presence or if they belong toclosed
Vulnerability
This has to be addressed before the removal of the first_class_vulnerabilities
feature flag to avoid migrating of the used-added data in the database.
Permissions and Security
The same per-Project privilege resolve_vulnerability
is used
Documentation
Update Vulnerabilities API documentation: Resolve Vulnerability
, other documentation that mentions possible states for Vulnerabilities.
Testing
Update relevant Vulnerabilities API
and underlying Vulnerabilities::*
services' tests.
What does success look like, and how can we measure that?
- Vulnerabilities have
resolved
state and means to set it via Vulnerabilities API - Vulnerability Findings derive their
resolved
state based on one of a parent Vulnerability