fix(api): return a boolean from endpoint_status mitigated under V3 Locations

[svader0]

Description

V3EndpointStatusCompatibleSerializer.get_mitigated returned a date instead of a boolean. It was a copy of get_date two methods above it:

def get_mitigated(self, obj) -> bool | None:
    return obj.created.date() if obj.created else None

On a tenant with V3_FEATURE_LOCATIONS enabled, this affects three fields of GET /api/v2/endpoint_status/:

• mitigated reports a date string on every row instead of true/false.
• mitigated_time and mitigated_by both branch on self.get_mitigated(obj). A date is truthy, so both answer as though every status is mitigated.

A client polling for mitigated statuses gets a wrong answer and no error.

The fix compares the status, which is what the three sibling methods below it (get_false_positive, get_out_of_scope, get_risk_accepted) already do:

def get_mitigated(self, obj) -> bool | None:
    return obj.status == FindingLocationStatus.Mitigated

Test results

Two new regression tests in unittests/test_endpoint_init_v3.py:

• test_endpoint_status_mitigated_is_a_bool_tracking_the_status asserts mitigated is a bool and is true only for Mitigated. It runs over all five FindingLocationStatus values.
• test_endpoint_status_mitigated_time_and_by_follow_mitigated asserts mitigated_time and mitigated_by stay null when the location is not mitigated.

Before the fix, 6 of the 7 cases failed:

AssertionError: datetime.date(2026, 8, 26) is not an instance of <class 'bool'> :
expected a bool for status=Active, got date datetime.date(2026, 8, 26)

The Mitigated case of the first test passed before the fix as well, because the date was truthy. It is the control case.

After the fix all 7 cases pass. Five other tests in that module fail on my local stack, before and after this change, because the stack forces SECURE_SSL_REDIRECT = True and they get a 301. They are unrelated to this change.

Documentation

docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md gains a bullet under "Behavioural Differences to Watch For" that records the old behavior, so a reader on an older release knows the field cannot be trusted.

Checklist

• Make sure to rebase your PR against the very latest dev.
• Features/Changes should be submitted against the dev.
• Bugfixes should be submitted against the bugfix branch.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is Ruff compliant (see ruff.toml).
• Your code is python 3.13 compliant.
• If this is a new feature and not a bug fix, you've included the proper documentation in the docs as part of this PR.
• Model changes must include the necessary migrations in the dojo/db_migrations folder.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.