Loading
Sync the tool coverage card with URL params
What does this MR do and why?
Sync the tool coverage card with URL params
Add tool_coverage_selection.js to map the card's scanner and status onto
the inventory URL params, and read the card's selection back from those
params in inventory_dashboard.vue, so the card and the filter bar derive
from one source. Delete toolCoverageFilterVariables and the
toolCoverageVariables parameter of filterQueryVariables, which built a
second set of query variables beside the bar's and overrode them on
hasScanners, hasStale and hasFailedOrWarning. Replace
TOOL_STATUS_TO_STATUS_FILTER with its inverse in constants.js, the
direction the card reads.
Treat the any-scanner status param and each scanner param as status
tokens. Show a selection on the card only when exactly one is set. Make
a status picked on the card replace every status token in the bar, and
make picking another scanner while the card shows a status remove that
token. Leave attribute, vulnerability count and search tokens in place.
Keep the chosen scanner in cardScanner so a scanner with no status
selected stays on the card without changing the URL.
Related to https://gitlab.com/gitlab-org/gitlab/-/issues/580024
Changelog: added
EE: truenote: The scanner dropdown now lists each sub-scanner with its own counts, and this leaves out business logic scanning until it has a filter token.
References
- issue: Frontend: Security inventory: add filters to UR... (#580024 - closed)
- was stacked on: Sync inventory filters with URL query params (!255954 - merged)
- renamed
All scannerstoAny scanner: Rename All scanners to Any scanner in the tool ... (!258868 - merged)
Screenshots or screen recordings
| testing instructions block | recording |
|---|---|
| to check the card syncs to the URL | clicking a state in the card adds the filter to the URL |
| to check the URL syncs to the card | card state matches when navigating directly to a URL with a controllable token |
| to check the card syncs from the search bar | adding a status token makes the card highlight that status with 2+ status tokens, the card is not highlighted |
| to check card clicks change the search bar | clicking a status in the card changes the token to match other token types are left alone |
| to check the card's scanner dropdown | changing the dropdown in the card clears the controlled token until a status is selected again |
| to check the state gets pushed to browser history | browser back and forward navigates through filter state history |
How to set up and validate locally
-
git checkout 580024-sync-tool-coverage-card-with-url-params echo "Feature.enable(:security_inventory_pagination, Group.find(ID))" | gdk rails c - have a GitLab Ultimate licence
- have a group with some projects that have scanners in different states
- go to the group =>
Secure=>Security inventory
to check the card syncs to the URL
- leave the card's scanner dropdown on
Any scanner - click
Failedin the card's legend - check that:
- the address bar gains
status=needs_attention - the search bar shows a
Statustoken forNeeds attention - the project list is filtered to match
- the address bar gains
- click
Failedagain - check that
statusleaves the URL, the token goes, and the list is unfiltered - pick
Dynamic application security testing (DAST)in the card'sAny scannerdropdown - check that the URL does not change yet
- click
Failed - check that the address bar gains
dast=failed, and the search bar shows aDynamic Application Security Testing (DAST)token forFailed
to check a sub-scanner
- pick
Secret push protection(a sub-scanner in the broader category of secret detection) in the card'sAny scannerdropdown - click one of the statuses in the card, like
Success - check that the address bar gains
secret_detection_secret_push_protection=success
to check the URL syncs to the card
- with
dast=failedin the URL, reload the page - check that the card's dropdown reads
Dynamic application security testing (DAST), withFailedselected - remove the token from the search bar
- check that the card no longer has a status selected
to check the card syncs from the search bar
The card highlights a status only when the search bar holds exactly one scanner or Status token.
- clear the search bar
- check that the card has no status selected
- apply a
Statustoken forHas stale scansfrom the search bar - check that the card switches to
Any scannerwithStaleselected - also apply a
Dynamic Application Security Testing (DAST)token forFailed - check that the card shows no status selected
- remove the
Statustoken - check that the card switches to
Dynamic application security testing (DAST)withFailedselected
to check card clicks change the search bar
- clear the search bar, then apply a token under
Security attributesand aVulnerability counttoken - with the card on
Any scanner, clickFailed - check that:
- a
Statustoken forNeeds attentionis added - the attribute and vulnerability count tokens stay
- a
- click
Stale - check that:
- the
Statustoken now readsHas stale scans, so it was replaced, not removed - the other tokens stay
- the
- apply a
Dynamic Application Security Testing (DAST)token forFailedfrom the search bar, so there are two - check that the card shows no status selected
- click
Enabledon the card - check that:
- both tokens are replaced by one
Statustoken forHas scanners enabled - the attribute and vulnerability count tokens stay
- both tokens are replaced by one
to check the card's scanner dropdown
- click
Failedwith the card onAny scanner, so the search bar holds oneStatustoken forNeeds attention - pick
Dynamic application security testing (DAST)in the card's dropdown - check that the
Statustoken is removed and the card has no status selected - click
Failed - check that a
Dynamic Application Security Testing (DAST)token forFailedis added
to check the state gets pushed to browser history
- click
Failedon the card, thenStale - press back
- check that the card, the search bar and the project list all return to
Failed - press forward and check they all return to
Stale
to run tests
yarn jest ee/spec/frontend/security_inventoryMR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #580024 (closed)
Edited by Miranda Fluharty