Deleting an engagement can promote duplicate findings without verified flag, preventing Jira creation

[marekcybul]

Bug description
Deleting an engagement that contains the current primary/original finding can promote or reactivate a duplicate finding from another engagement, but the promoted finding may remain unverified.

The resulting finding state is actionable but does not qualify for automatic Jira creation when Jira Project Settings use "Push All Issues", because DefectDojo only pushes findings that are both Active and Verified.

Observed promoted finding state after stale engagement deletion:

{
  "active": true,
  "verified": false,
  "duplicate": false,
  "risk_accepted": false,
  "severity": "High"
}

The finding is no longer marked as a duplicate and is active, but verified=false prevents Jira issue creation. This leaves a vulnerability visible in DefectDojo without the expected Jira ticket/workflow.

Steps to reproduce
Steps to reproduce the behavior:

1. Configure a Product with Jira Project Settings and enable Push All Issues.
2. Import a scan into engagement A with settings that create Active and Verified findings.
3. Import or reimport a matching finding in engagement B so that DefectDojo marks the engagement B finding as a duplicate of the engagement A finding.
4. Delete engagement A, or delete the engagement containing the current primary/original finding.
5. Observe that DefectDojo promotes/reactivates the duplicate finding from engagement B.
6. Inspect the promoted finding via the UI or API.
7. Observe that the promoted finding is active=true and duplicate=false, but verified=false.
8. Observe that no Jira issue is created for the promoted finding even though Product Jira Project Settings are configured to push all eligible findings.

In our environment this was observed with recurring scanner imports and stale engagement cleanup. One API-observed example after engagement deletion had active=true, verified=false, duplicate=false, risk_accepted=false, and High severity.

Expected behavior
When DefectDojo promotes/reactivates a duplicate finding because the original finding's engagement is deleted, the promoted finding should stay eligible for the same downstream workflows as the finding it replaces.

At minimum, DefectDojo should either:

• preserve or set verified=true when the promoted finding represents an active verified vulnerability, especially when the original/scan import settings were verified, or
• re-run the normal Jira push eligibility flow after promotion, or
• document and expose an intentional behavior if promoted duplicates are deliberately left unverified.

The key expectation is that deleting an engagement should not silently create an active primary finding that is skipped by Jira automation solely because verified was left false during promotion.

Deployment method (select with an X)

• Docker Compose
• Kubernetes
• GoDojo

Environment information

• Operating System: Kubernetes
• Docker Compose or Helm version (Output of docker compose version or helm version): Not available at time of filing
• DefectDojo version (see footer) or commit message: v. 2.58.3

Logs
No application traceback was observed. The issue appears to be a data/state transition problem during duplicate promotion after engagement deletion.

The downstream symptom is that Jira creation is skipped because the promoted finding is not Verified. DefectDojo's Jira documentation states that Product-level Push All Issues applies to findings that are Active and Verified:

https://docs.defectdojo.com/issue_tracking/jira/os__jira_guide/

Sample scan files
Not available yet. The issue was observed with recurring scanner imports and later stale engagement deletion.

Screenshots
Not included.

Additional context (optional)
This appears related to duplicate lifecycle handling rather than scanner parsing. The problematic sequence is:

1. Finding A is the primary finding in engagement A.
2. Finding B in engagement B is a duplicate of finding A.
3. Engagement A is deleted.
4. Finding B is promoted/reactivated as the remaining active primary finding.
5. Finding B remains verified=false.
6. Jira automation does not create an issue for finding B.

A regression test would be useful for:

1. Create a verified active finding in one engagement.
2. Create a duplicate finding in another engagement.
3. Delete the engagement containing the original finding.
4. Assert that the promoted replacement finding is active, not duplicate, and preserves/receives the expected verified state or otherwise triggers Jira eligibility handling.