Time to resolution date is inaccurate after setting the resolution and resolved date accurately

[Lisa Schachtschneider]

Original Problem: The postfunction to set the resolution was not in place, so we had to do a CSV import to set the resolution date according to the Status Category Change date, since the Closed/Canceled status (and date) was accurate. 

Outcome of the CSV import: The resolution and resolved date were set to a day in the past, which is accurate.

New problem: The SLAs were breeched and the Time to resolution captured the date of the bulk change instead of the resolved date. 

Update taken to remediate:

• Adding a new transition for closed status categories (Closed and Canceled) to clear resolution (if triggered) via bulk change.
  • Outcome: No change to SLAs, remain breeched and set to the date of the CSV import change

How can you reset the SLA calculation to be triggered on the bulk adding of the resolution and resolved date?

[Brant Schroeder · Accepted solution]

@Lisa Schachtschneider 

There will not be a way to update the SLA.  You might be able to create a new SLA and apply it.  The issue is that probably would not get you to what you are looking for as it would most likely mark them all as met.  I would suggest cutting your losses and moving forward with what you have. 

[Lisa Schachtschneider]

Hey @Brant Schroeder in speaking with support they did confirm the feature is not available in the UI but you can upvote the new feature in  https://jira.atlassian.com/browse/JSDCLOUD-9588 

From the referenced KB article I was able to use a curl command to recalculate the field and now see the green checkmarks showing the ticket met the SLA. 

https://confluence.atlassian.com/jirakb/slas-in-jira-service-management-are-missing-or-disappear-954252774.html 

[Brant Schroeder]

@Lisa Schachtschneider Thanks for posting back the solution.  Can you accept the answer so others can see the solution?