Never hide vulnerability modal footer
What does this MR do?
This ensures that the vulnerability modal always has an actions area/footer, even if the vulnerability it's displaying has been resolved (which can only happen within MRs).
Therefore, this should only have a visual effect on vulnerabilities fixed within a particular MR, when viewing that MR. The vulnerability modal is used elsewhere, for instance the Project Security Dashboard, but in those other places, vulnerabilities can't be "fixed", and so this should have no effect there.
Before this change, fixed vulnerabilities couldn't be interacted with at all, since their actions footer wasn't displayed. This meant that the user could not:
- dismiss the vulnerability
- create an issue for the vulnerability
- create a merge request to fix the vulnerability
- download a patch to fix the vulnerability
All of these restrictions still make sense, I think. The problem was that they weren't allowed implicitly before, whereas now they're disallowed explicitly.
Some details:
- The modal determines what to display based on a handful of
can*
props, e.g.,canDismissVulnerability
. These are simply permissions about vulnerabilities in general for the current user, and not specific to any given vulnerability. Since it's not meaningful to dismiss a resolved vulnerability, these permissions have been augmented to consider the current status of the vulnerability, via the newcan*ThisVulnerability
computed properties. - An unused computed prop
renderSolutionCard
was removed. - Some test code was cleaned up around the
SolutionCard
(preferring finding elements viaref
s and component classes overjs-*
) - Added/clarified some tests around when and why the modal rendered the footer. Previously, permissions were conflated with simply the existence of the footer.
See #32767 (closed) for more details.
Screenshots
Location/notes | Before | After |
---|---|---|
MR page (footer added with cancel button; mentions of downloading a patch/creating a merge request removed) | ![]() |
![]() |
Project Security Dashboard (unchanged) | ![]() |
![]() |
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry - [-] Documentation (if required)
-
Code review guidelines - [-] Merge request performance guidelines
-
Style guides - [-] Database guides
-
Separation of EE specific content