Fix: Suppress expected JIRA validation alerts when pushing (Fixes #12988)

[valentijnscholten]

Description

This PR fixes issue #12988 by suppressing unnecessary alerts when findings cannot be pushed to JIRA due to expected validation failures during automatic pushes.

Problem

When 'Push all issues' is enabled at the engagement level, DefectDojo attempts to automatically push all findings to JIRA during import/reimport. This causes alerts to be created for every finding that cannot be pushed due to expected validation failures (e.g., not verified, not active, below minimum threshold).

These alerts flood the Alerts UI with noise since these are expected conditions, not actual errors. Users cannot disable these alerts without also disabling alerts for real JIRA problems.

Solution

The fix distinguishes between:

• Expected validation failures: Findings that aren't ready to be pushed (not verified/active, below threshold, duplicates, etc.) - these are logged at INFO level but don't create alerts
• Unexpected errors: Configuration issues, connection problems, permission errors, etc. - these still create alerts as they indicate real problems

Changes

• Modified add_jira_issue() in dojo/jira_link/helper.py to check the error code returned by can_be_pushed_to_jira()
• Expected validation errors (error_not_active_or_verified, error_below_minimum_threshold, error_empty, error_inactive) are now logged but don't create alerts
• Duplicate findings are also handled as expected conditions
• All other errors (configuration, connection, etc.) still create alerts as before

Related Issue

Fixes #12988

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[paulOsinski]

@valentijnscholten these alerts are necessary at the UI level for troubleshooting why a Jira issue didn't push - especially in cases where users don't have access to software logs.

Maybe this could be a system setting toggle? But I don't want this to be off by default.

[valentijnscholten]

They're basically only off for unexpected situations not covered by the UI. Most cases should be covered by the UI not giving the option to push because the finding is not active for example.
An alternative implementation is that we make the alerting logic aware of whether it was a manual action via the UI or an automated action via the API. This would allow us to keep showing them for all UI action.

[paulOsinski]

Currently when you use Bulk Edit to push Findings to Jira, there is no warning raised in the UI preventing you from doing this, you simply get a confirmation that your action was successful along with your attempted Push To Jira. The only way you can tell that something didn't work is from Alerts.

I think this is something that could be fixed, but for now the UI doesn't do a great job of alerting you at least in that case.

[valentijnscholten]

@paulOsinski I created another PR focused on still generating alerts for UI initiated pushes to JIRA. But during testing those changes I found out that the UI initiated pushes already generate django messages on screen.

[mtesauro]

@paulOsinski I created another PR focused on still generating alerts for UI initiated pushes to JIRA. But during testing those changes I found out that the UI initiated pushes already generate django messages on screen.

Unless that UI is the Pro UI 😉

[valentijnscholten]

@Maffooch Which approach to you prefer? I'll wait with resolving conflicts until we know which way we want to go.

[Maffooch]

The only case we have left that does not alert is API based imports. I think it feels reasonable to suppress alerts when doing in this case only as the alerts do tend to flood the whole queue. If a user discovers a finding that should have been pushed, then the next step would be to attempt pushing the finding manually through the UI. In that case, the error message will be provided on screen

[valentijnscholten]

But not on Pro UI it seems?