Jira Cloud and Jira Data Center setup

Before connecting Jira

Use this page when the customer wants WebRiskOps to create or update Jira issues for report findings or generated fix tasks. Jira setup decides which Jira site can receive tickets before WebRiskOps asks for project, issue type or priority mapping. Start from `/settings` after Cloud and self-hosted integrations confirms the deployment mode. Do not enter Jira credentials until the customer-owned site, base URL, auth method and network path are clear.

Connect a Jira target

Follow the path `Cloud and self-hosted integrations → Jira target → Auth and network check → Jira export mapping → Revoke or fallback`.

1. Open /settings and review Integration status, then choose Jira Cloud or Jira Data Center setup. Result: provider_key is recorded as jira_cloud or jira_data_center before Jira fields are requested.
2. For Jira Cloud, confirm the Atlassian site URL belongs to the customer and choose OAuth or API token auth_method. Result: credentials are limited to the customer Jira site that will receive tickets.
3. For Jira Data Center, enter base_url only after the customer confirms ownership, reachable issue API and scan or export authorization. Result: deployment_mode is self-hosted and URL safety checks run before tokens are accepted.
4. Select scopes for project, issue and metadata access needed for ticket export. Result: WebRiskOps can validate project_key, issue_type, priority and Jira field schemes later without asking for broader access.
5. Review allowlist_status for self-hosted Jira Data Center. Result: firewall, VPN or approved tunnel state is visible before WebRiskOps tries provider API calls.
6. Save only when provider auth and network checks are ready. Result: the Jira target is available to ticket export without exposing secrets in documentation or support messages.
7. If PROVIDER_AUTH_REQUIRED appears, reconnect OAuth or the API token before retrying. Result: the target stays blocked until valid credentials exist.
8. If PROVIDER_BASE_URL_BLOCKED or PROVIDER_SCOPE_UNAVAILABLE appears, fix the URL or scope, or use portable fallback. Result: unsafe base URLs and unavailable Jira permissions do not receive evidence.
9. Continue to Jira export after setup. Result: issue field mapping and duplicate handling use the same Jira provider record.

Configure Jira authorization

Jira setup should collect only the access needed for the customer's export path.

• `jira_cloud` is for Atlassian-hosted Jira sites where OAuth or API token auth can reach the public Jira API.
• `jira_data_center` is for customer-owned Jira Data Center or Jira Server hosts that need a `base_url`, explicit authorization and network policy checks.
• `auth_method` should tell the customer whether OAuth, API token or another provider-supported method is required.
• `scopes` should allow project metadata, issue creation and issue updates, but not unrelated admin access.
• `allowlist_status` should be clear before WebRiskOps retries self-hosted Jira API calls.
• Revoke access in Atlassian first, then disconnect the Jira target in WebRiskOps so historical reports keep references without keeping live credentials.

Ready Jira integration states

Continue only when the Jira target can safely receive export work.

• Jira Cloud ready means `provider_key` is `jira_cloud`, the Atlassian site belongs to the customer and credentials are active.
• Jira Data Center ready means `provider_key` is `jira_data_center`, `deployment_mode` is self-hosted and `base_url` passed URL safety checks.
• Authorization ready means `auth_method` and `scopes` match the project and issue access needed for ticket export.
• Network ready means `allowlist_status` shows the target is reachable through a safe direct, allowlisted or customer-approved tunnel path.
• Revoke path ready means the customer knows where to revoke OAuth, API token or PAT access before disconnecting the WebRiskOps target.

Blocked Jira setup states

Blocked Jira setup should show the exact next action instead of asking for broader credentials.

• `PROVIDER_AUTH_REQUIRED` means reconnect Jira OAuth or the API token before saving or retrying export.
• `PROVIDER_BASE_URL_BLOCKED` means the Jira Data Center URL failed ownership, redirect, DNS, reserved-IP or private-network checks.
• `PROVIDER_SCOPE_UNAVAILABLE` means the saved auth method cannot read project metadata, create issues or update existing Jira issues.
• Missing `allowlist_status` means the self-hosted target cannot be trusted for automated provider calls yet.
• Required Jira fields, issue security or custom field schemes can still block Jira export after setup; those are handled on the Jira export page.

Continue after Jira setup

Continue to Jira export when the target is active and mapped to the customer project. Use Status sync and duplicate handling when a Jira issue already exists, Portable export fallbacks when Jira cannot be made safe, or GitHub.com and GitHub Enterprise Server setup when the remediation team works from GitHub instead.