Clear SLA manually?

[Esther Strom]

We have a fully-implemented service desk, with hundreds of tickets. We recently added a new SLA metric, but it's now showing that tickets that were created prior to that metric being implemented have breached that metric.

Is there any way for me (as a Jira site admin and service desk project admin) to manually mark this particular SLA metric as not breached for older tickets? We only want to see it on tickets that were created after the metric was added.

We have ScriptRunner, so if there's a way to do it via script, I can try that.

[Jack Brickey]

You can change the sla goal filter to only include issue after the date you turn on the sla. Such as “createddate > 2020-01-01 and...

[Esther Strom]

Oh, that's a good idea. Don't know why I didn't think of that. I'll give it a shot, thanks!

[Esther Strom]

I think I must be doing something wrong; editing the SLA to include the date does not update the tickets that have already been marked as having breached. Here's what my SLA looks like; note that I've tried both created and createdDate with the same result:

And here's what my queue looks like. Based on created > 2020-01-01, none of these issues should be marked as breached, but all of them are. I realize that in the queue, I could use the create date as part of the filter to hide any issues that were created after the SLA was added, but that won't actually remove the breached flag, and it will still affect any reporting we do.

[Jack Brickey]

trying to consume this but don't have all the info to do so effectively, i.e. priorities of issues and the sla rules itself. Can you share that info?

I guess what you were not expecting are the last two issues (-65h and -72h) to be shown or are are some of the other issues not expected?

[Esther Strom]

Most of those issues should not have been marked as breached. For example:

This issue has a priority of Low and was created 12/22/2019. Based on the SLA goal for Low priority, it should breach at 168 hours. It did; when I mouse over the SLA column, it shows the actual time spent as 264 hours, which does account for the -96 hours of breach time. But it was created before the date listed in the SLA goal, so I wouldn't expect it to display, based on what you said in your answer (include the date in the SLA goal to only include issues created after the SLA was turned on.)

ETA: never mind. They're all being caught by the "all remaining issues" goal. I'd need to write another goal to catch those; something along the lines of "if created before specific date, don't have a goal."

[Aaron St.George]

Curious if you were ever able to get this to work. For me I can write the JQL that shows exactly what I am after (breach on SLA after X issue created date) however when I add that to an SLA as a new custom goal, the All Remaining Issues still seems to override it.

[Esther Strom]

@Aaron St.George  - we did find a solution, but I don't think it's going to be helpful to you. In May, we had a requirement to start tracking SLAs on non-Service Desk tickets (i.e. how long does it take for an engineering team to deal with bugs of different priorities in classic software projects). In order to do this, we purchased a plugin that adds SLA functionality to all forms of projects, and in order to keep things consistent ended up using the plugin's reporting for our SD projects as well. So we're no longer using the native SLA functionality in Service Desk.