Jira export

Before choosing Jira

Use Jira export when the customer tracks remediation in Jira Cloud, Jira Data Center or Jira Server. Jira needs a project, issue type, priority and routing fields before WebRiskOps can safely create or update an external issue. Start from `/reports/{report}/ticket-exports` after the report finding or generated fix task is ready for external remediation. Do not choose Jira just because it exists in the account; choose it only when the destination team actually works from Jira.

Export a Jira ticket

Follow the path `Ticket export source → Jira target → Jira field mapping → Duplicate check → Jira issue or fallback`.

1. Open /reports/{report}/ticket-exports and select the report issue or generated fix task that belongs in Jira. Result: the selected source shows source_type, source_id, severity, affected URL and evidence-safe links.
2. Choose an active jira_cloud, jira_data_center or jira_server target for the same account and project. Result: provider_key and deployment mode match the Jira site that will receive the ticket.
3. For Jira Data Center or Jira Server, confirm the base URL passed the self-hosted URL and private-network policy checks. Result: WebRiskOps does not send issue data to an unsafe or unreachable Jira host.
4. Set project_key before export. Result: Jira knows which project owns the new issue or duplicate update.
5. Choose issue_type, priority, labels and components that match the finding severity and product area. Result: the Jira issue lands in the right workflow with enough routing context.
6. Check existing provider references and TICKET_EXPORT_DUPLICATE state before approval. Result: WebRiskOps updates or links the existing external_issue_id instead of creating duplicate Jira work.
7. Approve only after the Jira target, mapped fields and provider-neutral preview match the customer workflow. Result: WebRiskOps queues the Jira export and keeps status sync tied to the original source.

Map Jira fields

Jira needs enough destination fields before WebRiskOps can queue the ticket.

• project_key is the Jira project key that routes the ticket into the project that owns remediation work.
• issue_type should match the work type, such as Bug, Task or Story.
• priority should reflect WebRiskOps severity so high-risk findings do not arrive as unprioritized work.
• labels should identify the affected product area, such as checkout, consent-mode or security-headers.
• components should match the customer's Jira routing model when components are required.
• external_issue_id links repeat exports back to the existing Jira issue instead of creating duplicate work.

Ready Jira export states

Continue only when the Jira target and fields are clear.

• Jira Cloud ready means `jira_cloud` is active for the same account and project as the report.
• Jira Data Center ready means `jira_data_center` or `jira_server` is active and the self-hosted base URL is safe.
• Field mapping ready means project_key, issue_type, priority, labels and components are accepted by the selected Jira project.
• Preview ready means title, affected URL, evidence-safe links and acceptance criteria are visible before approval.
• Duplicate reference ready means an existing provider ticket can be opened or updated through Status sync and duplicate handling.

Blocked Jira states

Jira blocks should tell the customer exactly what to fix next.

• `jira_cloud_target_missing` means choose an active Jira Cloud target before exporting.
• `jira_cloud_target_inactive` or `jira_cloud_credential_missing` means reconnect Jira before retrying.
• `jira_cloud_validation_failed` shows the customer message "Jira rejected the ticket fields. Review the Jira project, issue type, priority, labels and component mapping, then retry."
• Unsafe self-hosted base URL means use a public HTTPS Jira URL, approved private-network policy or portable fallback.
• Rate limiting means wait for the automatic retry instead of approving the same source again.
• Missing project_key, issue_type or priority means finish Jira field mapping before queueing the export.
• Secret or private artifact in preview means redact evidence before sending the Jira issue.

Continue after Jira export

Continue to GitHub Issues export when the customer uses GitHub instead of Jira. Use Status sync and duplicate handling when a Jira issue already exists, Portable export fallbacks when Jira is unavailable, and Cloud and self-hosted distinctions when a Jira Data Center or Jira Server base URL is not clearly safe.