Feat/vulnerability audit filter query params

[duderoot]

Description

Filters on the Vulnerability Audit page are now reflected in the URL, so a filtered view can be bookmarked, shared with a colleague, or restored with the browser's back button. Previously the filter pills kept their state only in component data, so a URL always pointed at the unfiltered view and any selection was lost on reload.

Opening a URL such as

/vulnerabilityAudit/?severity=critical,high&cvssv3From=7&showKevOnly=true

restores those pills and loads the matching results directly.

The mapping is implemented generically in filterPillsMixin, but each view opts in explicitly, so only the two Vulnerability Audit tabs are affected by this change.

Addressed Issue

Related to #1191, which asks for filter state to be expressible in a link. That issue is about the project findings page (/projects/:uuid/findings), which does not use this mixin, so this PR does not close it — it introduces the mechanism that would make resolving it a small follow-up.

Additional Details

Query parameter format

One parameter per filter, named after the filter itself:

Filter type	Example
boolean	showKevOnly=true (omitted when off)
multi-select	severity=critical,high
text search	textSearch=log4j&textSearchFields=vulnerability_id,component_name
date range	publishDateFrom=2024-01-01&publishDateTo=2024-12-31
numeric range	cvssv3From=7&cvssv3To=9.5

Design notes

• Values from the URL are validated on the way in. Unknown enum values are dropped, numeric bounds are clamped to the filter's range, and malformed dates are ignored. A hand-edited or truncated URL degrades to a narrower filter rather than pushing junk at the API.
• Writes use replace() rather than push(). Refining a filter is a change to the current view, not a new destination, so adjusting five filters does not leave five entries to step back through. Leaving the page still behaves normally.
• A restored view costs one request, not two. The table's URL is built in data(), before filters are read from the query string, so hydration rewrites it before the table component is created. Otherwise every bookmark would fire an unfiltered request followed immediately by the real one.
• The two audit tabs share a single query string. A view therefore only writes the query while its tab pane is visible, and leaves parameters it does not recognise untouched. That way switching tabs preserves the other tab's filters instead of clobbering them.
• Opt-in per view. PolicyViolationAudit, ComponentSearch and WorkflowRunList share this mixin and are deliberately left unchanged. Extending it to them is a matter of setting filterUrlSync and declaring a type per filter.

Drive-by fix

VulnerabilityAudit.vue discarded the query string when switching tabs, because it compared fullPath (which includes the query) and then pushed a bare path. It now compares path and carries the query along. Without this the feature could not survive a tab switch.

Tests

This repository had no test runner, so the first commit adds Jest with jsdom and @vue/test-utils, exposed as npm test / npm run test-watch / npm run test-coverage, with specs under tests/. Vue SFC compilation is deliberately left out: the code under test is plain JavaScript, so the setup does not depend on vue-jest.

The feature is covered by 35 tests spanning encoding, decoding, rejection of untrusted values, back/forward navigation, and the tab-gating rules. Two bugs were found and fixed while writing them: a numeric range could be dropped when a query object round-tripped in memory rather than through a URL, and the decoder rejected non-string scalars.

Verified manually against a Dependency-Track 5.0.0 API server as well: applying each filter type updates the URL, reloading restores every pill, switching tabs preserves state, back/forward works, and "Clear all" empties the query string.

Checklist

• I have read and understand the contributing guidelines
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[owasp-dt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[nscuro]

Can we find a way to massively trim down the changeset of this PR? 30k lines added / 20k removed is way too much for what this PR aims to implement.

[duderoot]

@nscuro I agree with you—maybe it's too much for a single commit. The thing is, we should also start adding some infrastructure for testing. So I'll move the testing setup to a separate branch.

In the long term, the UI tests should give us confidence that changes to the UI don't break other parts of the application. 🙂

[duderoot]

Testing with some new test for the existing code was created in the PR for #1722
In this PR I reverted the test infrastructure.