-
Bug
-
Resolution: Done
-
Low
-
None
-
1.2.1
Issues that are considered resolved are not having their SLAs update accordingly reports in the service. The reports will not accurately represent the actual data. This means that even though a team may have already dealt with 1000+ issues the SLAs and associated reports will only show new information. Especially when dealing with a "Time to Resolution Average" If the goal was originally 240 hours based on a 24/7 calendar, when changed that to a specific calendar (say a 9-5 based calendar) and a 9 hour goal the averages will be thrown way off.
The problems pertain exclusively to historical issues. (ie issues that were marked as resolved before the change to the SLA took place)
For example let's build a mock timeline:
01-01-2014
Create SLA "Time to Resolution"
Goal is 240 hours based on a 24/7 calendar
01-02-2014 -> 02-01-2014
Create and Resolve numerous tickets
02-02-2014
Modify the SLA "Time to Resolution"
-NEW goal is 8 hours based on a custom 9am-5pm calendar
02-03-2014 ->
Create and Resolve numerous tickets
The problem is that the tickets created and resolved during the "01-02-2014 -> 02-01-2014" phase do not have updated SLAs. Those tickets still present to me SLA data from the initial creation of the SLA on 01-01-2014 (goal being 240 hours) instead of updating the SLA to match the new SLA criteria that was established on 02-02-2014. According to the documentation (https://confluence.atlassian.com/display/SERVICEDESK/SLAs):
SLA usage notes
If you edit an existing SLA, JIRA Service Desk will re-index all the existing issues in the project; the re-indexing will ensure that the SLA status on the issues accurately reflects any changed criteria. All the historical SLA data will be recalculated to measure against the new metrics.
As stated previously, all issues should have their SLA data updated to match the current SLA goals and criteria.
In the attached screenshots you can see the following:
SLA Time to Resolution.png
Shows that the SLA "Time to Resolution" is configured for 9 hours, based on the OPI (9am-5pm) calendar and for issue type "ScanIt Support Ticket"
Issue with incorrect SLA.png
Shows that a "ScanIt Support Ticket," that was created and resolved before the SLA modification took place, displays information based on SLA goals that do not exist anymore.
Issue with correct SLA/png
Shows what I expect to see on all "ScanIt Support Ticket" issues, even historical issues. You can see that the SLA is set to a 9 hour goal like how it is configured in the Service Desk SLAs for the project.
- duplicates
-
JSDSERVER-358 SLA is not enabled for closed issues
-
- Closed
-
- mentioned in
-
Page Failed to load
Form Name |
---|