Refactor vulnerability-details component for better reusability
What does this MR do?
This refactors the vulnerability component to:
- receive a
vulnerability
prop: #14006 (closed) - explicitly write the markup for the details of the vulnerability: #32039 (closed)
This has also involved removing various store mutations and state.
There are only some minor UI changes:
- In Merge Requests, the component now displays (if available):
- the project the vulnerability belongs to
- the report type of the vulnerability
- the line number information for the
file
- In Security Dashboards, the component now displays (if available):
- the method in which the vulnerability was detected
This MR thus unifies how vulnerabilities are rendered, regardless of the context. Previously, both contexts were lacking in some way.
Screenshots
Before | After | |
---|---|---|
MR context | ![]() |
![]() |
Security Dashboard context | ![]() |
![]() |
Please do not squash this!
The story of how this MR was developed is conveyed by its commits, and has some useful information that should be preserved. As such, I'd prefer that they be left intact
Unfortunately, viewing the individual commits within GitLab may be tricky, since some are very large due to the temporary snapshot files used in the refactoring process. These are probably best viewed locally in your favourite diff viewer.
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
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Edited by Mark Florian