Skip to content

fix: relabel finding Asset-tag (AND) filter to v3 Asset vocabulary#15136

Open
stevewallone wants to merge 1 commit into
DefectDojo:bugfixfrom
stevewallone:fix/finding-filter-asset-tag-labels
Open

fix: relabel finding Asset-tag (AND) filter to v3 Asset vocabulary#15136
stevewallone wants to merge 1 commit into
DefectDojo:bugfixfrom
stevewallone:fix/finding-filter-asset-tag-labels

Conversation

@stevewallone

@stevewallone stevewallone commented Jul 1, 2026

Copy link
Copy Markdown

Description

The v3 Product→Asset relabel (#13155) centralises filter copy in dojo/asset/labels.py, gated by ENABLE_V3_ORGANIZATION_ASSET_RELABEL (default on). The Asset-level AND tag filter on the finding list (test__engagement__product__tags_and in FindingTagFilter) was left with a hardcoded "Product Tags (AND)" label and help text, so it kept the legacy wording even with the relabel enabled — inconsistent with:

  • its siblings Test Tags (AND) / Engagement Tags (AND), and
  • the OR variant, whose label is already set dynamically to Tags (Asset).

This wires the AND field to the edition-aware labels by adding ASSET_FILTERS_TAGS_ASSET_AND_LABEL and ASSET_FILTERS_TAGS_ASSET_AND_HELP to both vocabulary branches, so the field renders:

  • v3: Asset Tags (AND) — help text "Filter Findings by the selected Asset tags (AND logic)"
  • legacy edition: Product Tags (AND) — unchanged

The OR variant (test__engagement__product__tags) is intentionally left untouched: its label is set dynamically at render time by get_tags_label_from_model()Tags (Asset), which already overrides any static declaration.

Test results

Adds a regression test unittests/test_filter_asset_tag_labels.py that asserts the rendered FindingFilter form field (not the static declared label=, which the dynamic setter can override) carries the Asset vocabulary. Verified RED→GREEN, and the surrounding filter/label unit tests pass. manage.py makemigrations --check is clean — no model or migration changes.

Documentation

The one docs screenshot that shows this label (OS__tagging_objects.md, "Filtering for Tags") is refreshed in a separate, dependent docs PR against dev. No doc changes here.

Checklist

  • Bugfix submitted against the bugfix branch (branch is on the current bugfix tip).
  • Meaningful PR name for release notes.
  • Ruff compliant.
  • Python 3.13 compliant.
  • No model changes / migrations (verified makemigrations --check).
  • Unit tests added.
  • Categorised as a bugfix — please add the bugfix label (fork PRs can't set labels).

The v3 Product->Asset relabel (DefectDojo#13155) centralises filter copy in
dojo/asset/labels.py, gated by ENABLE_V3_ORGANIZATION_ASSET_RELABEL
(default on). The Asset-level AND tag filter on the finding list
(test__engagement__product__tags_and) was left with a hardcoded
"Product Tags (AND)" label and help text, so it kept the legacy wording
even with the relabel enabled -- inconsistent with its siblings
"Test Tags (AND)" / "Engagement Tags (AND)" and with the OR variant,
whose label is already set dynamically to "Tags (Asset)".

Wire it to the edition-aware labels by adding
ASSET_FILTERS_TAGS_ASSET_AND_LABEL and ASSET_FILTERS_TAGS_ASSET_AND_HELP
to both vocabulary branches, so the field reads "Asset Tags (AND)" in v3
and remains "Product Tags (AND)" in the legacy edition.

Adds a regression test asserting the rendered FindingFilter form field.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@valentijnscholten valentijnscholten added this to the 3.1.0 milestone Jul 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants