Fix #10268: Make Finding Group filter context-aware (Test/Engagement/Product)

[AbhimanyuGit2507]

Description

Fixes #10268 — the Finding Group filter displayed groups from unrelated Tests or Engagements when viewing findings within a specific context.

This PR makes the Finding Group filter context-aware so that the dropdown only shows relevant groups:

• Test view: only groups belonging to that test
• Engagement view: groups from tests in that engagement
• Product view: groups from tests in that product
• Global findings view: all authorized finding groups (unchanged behavior)

Implementation details

• Added a helper function to build a Finding Group queryset based on context (test → engagement → product → global).
• Passed engagement and test context from finding views into the filter.
• Updated both FindingFilter and FindingFilterWithoutObjectLookups to ensure consistent behavior.
• Authorization is applied after context filtering, following the same pattern used in finding groups: filter by product if applicable #12711.
• Added minor query optimization to load only required fields for the dropdown.
• No model changes or migrations were introduced.

Test results

Added unit tests in dojo/unittests/test_finding_group_filter_context.py covering:

• Filtering in Test context
• Filtering in Engagement context
• Filtering in Product context
• Global context behavior
• Hierarchy precedence (test > engagement > product)
• Behavior of both filter classes

All tests pass locally.

Documentation

No documentation updates required. This change corrects filter behavior without altering user workflows or APIs.

Checklist

• Make sure to rebase your PR against the very latest dev.
• Bugfix submitted against the correct branch.
• Give a meaningful name to your PR.
• Your code is flake8 compliant.
• Your code is python 3.13 compliant.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR (bugfix).

[dryrunsecurity]

🔴 Risk threshold exceeded.

This pull request modifies multiple sensitive codepaths (dojo/filters.py, dojo/finding/views.py, dojo/test/views.py), with the scanner flagging these edits as sensitive and recommending configuration of allowed authors and paths in .dryrunsecurity.yaml; the changes are marked as failing-level risk but not currently blocking.

🔴 Configured Codepaths Edit in dojo/filters.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/filters.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/finding/views.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/test/views.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

We've notified @mtesauro.

---

All finding details can be found in the DryRun Security Dashboard.

[valentijnscholten]

I asked Sonnet 4.5, can you check if there's some valid point in there?

1. Missing defensive checks in set_related_object_fields()

In FindingFilterWithoutObjectLookups.__init__() (lines 57-80), field deletions use defensive checks:

if "test__engagement__product__name" in self.form.fields:
    del self.form.fields["test__engagement__product__name"]

However, in FindingFilter.set_related_object_fields() (lines 112-120), fields are deleted without checks:

del self.form.fields["test__engagement__product"]
del self.form.fields["test__engagement__product__prod_type"]
del self.form.fields["test__engagement"]
del self.form.fields["test"]

Recommendation: Add defensive if field in self.form.fields checks for consistency and to prevent potential KeyError exceptions.

2. Potential N+1 query in engagement context

Line 122 performs a database query each time the filter is instantiated:

engagement = Engagement.objects.get(id=self.eid)

Recommendation: Consider caching this or refactoring to avoid the extra query if multiple filters are created.

[valentijnscholten]

see above

[AbhimanyuGit2507]

I asked Sonnet 4.5, can you check if there's some valid point in there?

1. Missing defensive checks in set_related_object_fields()

In FindingFilterWithoutObjectLookups.__init__() (lines 57-80), field deletions use defensive checks:

if "test__engagement__product__name" in self.form.fields:
    del self.form.fields["test__engagement__product__name"]

However, in FindingFilter.set_related_object_fields() (lines 112-120), fields are deleted without checks:

del self.form.fields["test__engagement__product"]
del self.form.fields["test__engagement__product__prod_type"]
del self.form.fields["test__engagement"]
del self.form.fields["test"]

Recommendation: Add defensive if field in self.form.fields checks for consistency and to prevent potential KeyError exceptions.

2. Potential N+1 query in engagement context

Line 122 performs a database query each time the filter is instantiated:

engagement = Engagement.objects.get(id=self.eid)

Recommendation: Consider caching this or refactoring to avoid the extra query if multiple filters are created.

yes both points are valid, I will update the field deletions to protect against missing fields. I’ll also switch the engagement lookup to a safer pattern to avoid unnecessary queries.

[AbhimanyuGit2507]

Both changes are done as requested, let me know if any other changes are required.

[valentijnscholten]

did some manual testing also and looks good to me