Missing or corrupted SLA data in Jira Service Management
This article is about Jira Service Management Server. For the Cloud equivalent, see SLAs in Jira Service Management are missing or disappeared.
問題
In Jira Service Management, there can be an occurrence where the SLA data for the issue is missing or doesn't stop when it should. This Knowledge Base does not provide information on how to solve the issue once and for all, as the root cause can vary from add-ons/database corruption/other unknown causes, but it provides a viable workaround for the missing SLA.
診断
環境
- Jira Service Management Server version 3.0.3 or above
症状
- An example case is the missing 'Initial Reaction Time' SLA in the issue
- SLA is not showing on both ticket and issue navigator searches
- There are SLA data in the database for the affected issues but the SLA is either missing or incorrectly displayed on the UI e.g. still running when they should already be stopped.
- Refer to this documentation to verify from the database the SLA data is indeed missing
原因
Multiple causes at the moment:
- Corrupted database
- Plugin Issue
- Known Bugs like Multiple SLA updates in the same request override each other, SLA Custom Field should select the last updated value if there is a race condition.
回避策
Before running the reconstruction of SLAs using REST API you can now recalculate SLAs from UI, you can
As mentioned in the Jira Service Management 5.0.x release notes you can now recalculate SLAs from UI for JSM version >= 5.0.x so please try the below before trying the REST calls if this happening with a few issues and check if that fixes the issues with SLAs
課題の SLA を再計算する方法。
課題に移動します。
In the SLAs section, select More actions (…) > Recalculate all SLAs .
Select Recalculate.
Below are ways to temporally circumvent a problem, although it still exists in the application.
If you are running JSD 4.3.0 and above, you will need to first enable the dark feature sd.sla.fix.timeline .enabled per the instructions in Enable Dark Feature in Jira:
Navigate to the following page to access the Dark Features page:
<baseUrl>/secure/admin/SiteDarkFeatures!Default.jspa
- Enter sd.sla.fix.timeline.enabled in the field “Enable dark feature” and clicking on the “Add” button, and verify that the dark feature sd.sla.fix.timeline.enabled is showing:
Perform a POST-REST call to the Jira instance through the following URL:
<baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct
- In the Authorization tab, select 'Basic Auth' type and supply your Jira credentials accordingly
Along with the header: "Content-Type: application/json" and raw JSON data below within the Body section.
["ISSUEKEY-XXX", "ISSUEKEY-XXXX"]
Key in the issue key for the issue which has the missing SLA.
You may install Postman offered by Chrome Web Store to achieve this. Please make sure you're sending a POST request with raw data with JSON application .
Alternatively, you can use the CURL command-line tool to do this:
$ curl -X POST -u $USERNAME:$PASSWORD -H "Content-Type: application/json" "http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct" -d "[\"TEST1-2\", \"TEST1-3\"]"
- Performing the above will trigger a manual reconstruction of the SLA.
- Navigate to the Service Management Project Administration and click on the "Update" icon under the SLAs section.
Using the Automation for Jira to schedule an automatic reconstruction:
- Create a Global Automation Rule.
- Select a "Scheduled event" trigger for every 1h or another period that best fits your case.
- Mark the "simply run" checkbox option on the scheduled trigger.
- For the action, select the: "Send web request" block:
{{baseURL}}/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql
You'll still need to enable the dark feature before applying this workaround.
Authorization = Bearer <personal-token>
You can generate a personal token on the Profile options for the admin making this rule. Be aware that the PAT will be available to any other admin that can access this rule's configuration. If you want to avoid this, you can create a dummy user with only the required permissions and use this dummy user instead of a regular admin user account.
Content-Type > application/json
Required to send the JQL.
"SLA-NAME" = outdated() AND created > -2h
To avoid unnecessary recalculation be sure to use a JQL that gets only the affected issues as every time this rule run, Jira will recalculate all the SLAs even if they aren't missing or broken.
5. Create a new name, save and publish the new rule.
6. You can click the button "Run rule" button to run the rule and check the Audit log to make sure it works.
Service Management 4.9.1 added a few more REST endpoints to help
- /rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql
- Similar to "/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct" but it takes a valid JQL expression instead of the list of issues to get the issues to be reconstructed.
Not providing any JQL will cause an empty JQL to be executed which will return all issues on the instance , and will run reconstruction on all of them. Use with caution.
$ curl -X POST -u $USERNAME:$PASSWORD -H "Content-Type: application/json" "http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql" -d "Project=TST"
/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/force
- Similar to <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct, but it will not take into account whether any events are missing or out of order. It will recalculate the SLA based on current SLA settings (which might have changed since the time the issue SLAs were calculated) and force overwrite the values in the DB for each issue provided to the API in the request body.
- Be EXTREMELY careful when running this one. The changes are irreversible, and the new calculated values will take into account only the current SLA settings that may not be the same as when the SLAs were originally calculated for the ticket.
- Similar to <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct, but it will not take into account whether any events are missing or out of order. It will recalculate the SLA based on current SLA settings (which might have changed since the time the issue SLAs were calculated) and force overwrite the values in the DB for each issue provided to the API in the request body.
- /rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql/force
- Similar to <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql, but it will not take into account whether any events are missing or out of order. It will recalculate the SLA based on current SLA settings (which might have changed since the time the issue SLAs were calculated) and force overwrite the values in the DB for each issue returned by the provided JQL.
Be EXTREMELY careful when running this one. The changes are irreversible, and the new calculated values will take into account only the current SLA settings that may not be the same as when the SLAs were originally calculated for the ticket.
Not providing any JQL will cause an empty JQL to be executed which will return all issues on the instance, and will run reconstruction on all of them. Use with EXTREME caution.
- Similar to <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql, but it will not take into account whether any events are missing or out of order. It will recalculate the SLA based on current SLA settings (which might have changed since the time the issue SLAs were calculated) and force overwrite the values in the DB for each issue returned by the provided JQL.
This script was build to help running the /rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct endpoint using a JQL on versions earlier than 4.9.1.
- Service Desk SLA Regen.py
- Python3 and requests are needed to run it
ソリューション
For below root cause:
- Corrupted database: Above workaround should fix the missing data
- Plugin Issue: Perform Safe Mode on the test instance to see if the SLA is still missing
For other unknown root causes, please consult Atlassian Support for further investigation