Jira Integration
MIDDAG Account integrates with Jira Service Management for service request tracking, SLA monitoring, and worklog management. Jira is the SLA engine -- the plugin displays SLA status and aggregates data for reporting, but it does not run its own SLA clock.
Core principle
Jira applies SLAs (pause/resume, calendars, holidays). The plugin mirrors the status. Running parallel SLA clocks would create drift and require maintaining two timing engines. Jira is the single source of truth for SLA state.
Setup
API credentials
| Variable | Description | Required |
|---|---|---|
JIRA_DOMAIN | Atlassian domain (e.g. middag) | Yes |
JIRA_EMAIL | Integration user email | Yes |
JIRA_API_TOKEN | API token for the integration user | Yes |
The plugin connects to Jira Cloud at https://{JIRA_DOMAIN}.atlassian.net/rest/api/3. Authentication uses HTTP Basic with email and API token.
Graceful degradation
If the environment variables are not set, the Jira integration is silently disabled. All Jira service methods return gracefully, and the rest of the plugin works normally. This is the same pattern used for all optional integrations.
Data flow: Jira to Plugin
Jira sends webhooks to the plugin for issue lifecycle events:
Periodic reconciliation
A cron job catches missed webhooks:
| Frequency | Action |
|---|---|
| Every 15 min | Check for SRs with divergent status |
| Daily | Reconcile SLA fields for all open SRs |
| Weekly | Generate SLA compliance report |
Data flow: Plugin to Jira
The plugin also creates and manages issues in Jira.
Automatic issue creation from orders
When a WooCommerce order is completed, the plugin checks each order item for Jira configuration. If a product has _middag_jira_enabled = yes, the plugin creates a Jira issue automatically.
Product meta keys for Jira configuration:
| Key | Description |
|---|---|
_middag_jira_enabled | Enable Jira issue creation (yes/no) |
_middag_jira_project_key | Jira project key (e.g. MIDDAG) |
_middag_jira_issue_type_id | Issue type ID |
_middag_jira_summary_template | Optional summary template |
REST API endpoints
The plugin exposes Jira operations through its own REST API:
| Method | Endpoint | Description |
|---|---|---|
| GET | /jira/projects | List Jira projects |
| GET | /jira/projects/{key}/issue-types | Issue types for a project |
| POST | /jira/issues | Create an issue |
| GET | /jira/issues/{key} | Get an issue by key |
| PUT | /jira/issues/{key} | Update an issue |
| GET | /jira/issues/search?jql=... | JQL search |
| POST | /jira/issues/{key}/transitions | Transition an issue |
| POST | /jira/issues/{key}/comments | Add a comment |
All endpoints are prefixed with middag-account/v1.
Source of truth by data type
| Data | Source of truth | Direction |
|---|---|---|
| Issue status | Jira | Jira to Plugin |
| Priority | Jira | Jira to Plugin |
| SLA elapsed time | Jira | Jira to Plugin |
| SLA breach events | Jira | Jira to Plugin |
| Estimated UST | Plugin | Plugin to Jira |
| Actual UST | Plugin | Calculated |
| Billed amount | Plugin | Not synced |
| Service type | Plugin | Plugin to Jira |
| Subtasks and boards | Jira | Not synced |
Worklog tracking
Jira worklogs feed into the plugin's UST (unit of service time) calculations. When a service request is resolved, the plugin reads worklogs from Jira and calculates the actual time spent. This data is used for billing and SLA compliance reporting.
Rate limiting
The Jira client respects HTTP 429 responses with Retry-After headers. Maximum of 3 retry attempts with the delay specified by Jira. Request timeout is 30 seconds.