Jira: support fields on close/reopen transitions

[devGregA]

Description

Some Jira workflows require specific fields to be present on a transition screen — e.g. a workflow that refuses to close an Issue unless a Resolution and a justification custom field are provided. DefectDojo currently fires close/reopen transitions with only a transition ID (jira_transition passes nothing else to jira.transition_issue), making such workflows impossible to satisfy: the transition is rejected and findings/issues drift out of sync.

This adds two JSON settings on JIRA_Project, mirroring the existing custom_fields pattern:

• close_transition_fields — sent as the fields payload of every close transition
• reopen_transition_fields — same for reopen

Example:

{
    "resolution": {"name": "Won't Fix"},
    "customfield_10200": "Risk accepted by security team"
}

The payload is applied at every transition call site: status pushes (close + reopen in push_status_to_jira), the deleted-finding close task (fields are captured at dispatch time since the finding/JIRA_Issue rows are gone when the task runs), and the raw-REST epic close. Form and API serializer expose the new settings with the same inheritance and JSON-coercion behavior as custom_fields.

Documented limitation: one static blob per close/reopen — the values cannot vary per finding disposition (a fixed-close and a false-positive-close send the same fields). The docs section added here calls that out.

Test results

unittests.test_jira_helper: 33/33 pass — new JIRATransitionFieldsTest covers jira_transition with/without/empty fields (legacy call preserved byte-for-byte when unset), close/reopen payload selection in push_status_to_jira (including project resolution when no project is passed), the deleted-finding task passing dispatched fields, and the epic-close REST payload with and without configuration. Existing dispatch/transition assertions updated for the new keyword.

Documentation

docs/content/issue_tracking/jira/PRO__jira_guide.md gains a "Close / Reopen Transition fields" section with the example above, the transition-screen requirement, and the static-blob limitation.

🤖 Generated with Claude Code

[paulOsinski]

Tested this one:

• Built a Jira test project with a strict workflow: issues can't be closed or reopened without a resolution and a justification field
• Reproduced the issue: current DefectDojo sends no fields, Jira rejects the transition with a 400, finding and issue drift out of sync

Local testing

• Ran the PR branch locally, closed and reopened a finding: Jira accepted both with configured fields sent
• Sent a resolution but no justification: Jira still rejected it, so the full field set is required
• Confirmed drifted issues get fixed on the next push once the config is corrected
• Verified the new settings work through the REST API: /api/v2/jira_projects/{id}/ can be accessed through GET and modified through PATCH methods

{
  "close_transition_fields": {"resolution": {"name": "False Positive"}, "customfield_10255": "Closed from DefectDojo E2E test (PR 15213)"},
  "reopen_transition_fields": {"customfield_10255": "Reopened from DefectDojo E2E test (PR 15213)"}
}

Note that modern Jira auto-fills resolution on close, so you need custom fields if you actually want to "block" issue closure. If your workflow just "requires a resolution" without a custom field, Jira will simply pick a default resolution and close the issue anyway.