Workaround

To enable SLAs for already resolved issues, use the REST API SLA reconstruction call from this KB article: https://confluence.atlassian.com/jirakb/missing-or-corrupted-sla-data-in-jira-service-management-828790603.html

This reconstruction call will ignore the fact that the issue was already resolved, and will add the SLA to this issue.

Michael,

Can you weigh in on whether this issue: https://support.atlassian.com/servicedesk/customer/portal/3/SDS-3399 applies to this issue.

My feeling is that it does not, but you're better positioned than I am to decide.

Thanks,

Dan

Please be aware that since VertygoSLA is deprecated, this policy is blocking our company from migrating SLA to Service Desk and as a result from upgrading JIRA. We do not want to lose our SLA from Vertygo, yet because of this policy, SLA for closed old issues will get reset, which we can't accept. Please provide solution.

Problem described in JSD-699

Michael,

Ok, I see what you are getting at and would tend to agree: in principle, don't recalcuate closed issues.

But nothing stands in the way of calculating closed issues (notice the missing "re"). For example, when an SLA is first created there could be an option to apply it to closed issues.

In fact, maybe that option should also be available when SLAs are modified, since one might not get it right on the first save. Providing the option just puts the power in the hands of the user, which is good.

What is the argument against this liberal policy?

Regards,
David

Michael,

Makes sense - I see what you`re getting at. That said, I think the option should be there to re-calculate - or perhaps the ability to store original values in some way. Take for example, out company has various SLA timers. Our SLA has never changed and likely never will. However, we`ve made changes to workflows and whatnot and as a result, some issues ended up with different start and end points and sort of became orphaned. For instance, an issue can be of type "User Request" or of type "Task". User Request goes through things like 'acknowledgements, stall states and more importantly a resolved state - which is not a closed state (allows hypothetical managers to say, hey, this isn`t really resolved etc.) where ask Task, is just open-> closed. But I want a first response and time to resolution timer for both, but those timers didn`t have the right values in them to start with as our workflows have evolved. As a result, in a few instances we ended up with issues that had -6000 hours because an issue was never 'resolved' even though its closed because initially, the workflow would allow you to go from a newly created issue straight to closed, so the "Entered Status: Resolved" or "Resolution Set" (can`t remember which) never got set and as a result the timer just kept going.

Does the functionality exist to deal with this? I can change the SLA first response timer to start with issue creation and stop with `Stalled,Closed,Entered status: Resolved,Resolution Set` etc., but it either doesn`t work or the timer just disappears entirely from the issue... There doesn`t appear to be any javadocs for JSD so I don`t even know where to begin to script something..

Only Time metrics are applied retroactively, not SLA outcomes. This works as intended, but I understand that it might be confusing, so let me elaborate on the how and why

Service Desk has three different concepts that are currently displayed on the same configuration page: Time Metric Configuration, Goals and SLAs. Note that the page lists all under "SLAs" tab, which is partially misleading as the first two apply more to reporting, something we might improve in a future version.

1. Time Metrics
The definition of Start, Pause and Stop defines how metrics are gathered. When should the timer start, during what conditions should it pause and when should it stop. Service Desk can recalculate this information using the issue change history or update whenever issues are being changed. As a result, data from the past is available after enabling a Service Desk. Similarly, if you change the configuration, Service Desk can recalculate the metric data based on the new configuration.

2. Goals
Goals allow you to subdivide issues into different groups (defined by JQL search), and allow you to apply different calendars to these issues. Why is this important? Well, the calendar forms part of the time metric definition. Should the timer only count during business hours, should it be 24/7, are Public Holidays taken into account? Having multiple goals allows you to apply different calendars depending on the shape of the issue. One common use case would be to have a time zone / support zone field and base the actual calendar used on which support zone an issue originates from.

Changing the calendar for an issue doesn't change the stored time metric data (the issues still started, paused and stopped at the exact same time), but it will change the calculated "elapsed time" for an issue. Note that thus far there is no concept of "remaining time", as we need an actual time limit for this.

3. SLAs
SLAs define a time limit for a time metric. On the SLA configuration page the "Duration/Target" column inside the goals are the actual SLAs. If the value is empty no SLA applies to its issues, otherwise the hours/minutes are the actual SLA time limit.

Having elapsed time information together with the time limit, we can now calculate the remaining time for an ongoing SLA.

Now, contrary to time metrics, SLAs are NOT recalculated for the past. This is intentional because we decided to not recreate history for SLA outcomes because lines become really really blurry once you do: What would the SLA outcome for an issue actually mean?

What SLA value would you expect for an already close issue after enabling Service Desk? The value that the current configuration yields? I see why this might be interesting, but is it actually true? Was there an SLA before you enabled Service Desk? The answer might be yes and yes, so lets just do it and put in the SLA values as recalculated from the predefined time metrics at the point of enabling Service Desk.

Lets now go in and change the time metric/goals/goal duration configuration, because, why not, defaults aren't always right. Maybe we want to pause the timer until the issue is assigned to a user. Changing the time metric definition will result in the time metric values being recalculated, which will result in the SLA outcomes to likely change as well. But: What SLA value would you expect for already closed issues now? Should we apply the now current configuration to all issues in the past, even the ones that got stored after you enabled service desk or should we keep SLA values where available and just add some values where missing? We could, but doesn't really matter either way because we just got started anyways, so lets just wipe everything and start afresh.

So that was back in October 2013, our company had a target SLA of 8 hours throughout. Since then the team worked against that SLA, they smashed it, 98% succeeded rate. Come January 2014 the company decides to change the SLAs down to 4 hours. New year, new target. As a result of this change all time metrics will be recalculated again. Makes sense, but for SLA outcomes the whether to recalculate or not question becomes a tricky one: Should we wipe all 2013 SLA outcomes and apply a 4h throughout? Remember that team with the 98%? Well they are now down to 12%, bad luck I'm sure you agree with me that in this case you wouldn't expect the 2013 SLAs to change, because they were valid targets and valid outcomes at that time.

This is where lines become really blurry. Our feeling was and still is that whatever SLA configuration is in effect at a given time is what defines the SLA limits for ongoing issues. If you change the configuration, all in-progress issues will be affected, all future issues will be affected, but all past issues will be left as-is. If they didn't breach in the past they are left as un-breached, if they breached in the past they are left as breached even if under the new SLA rules they wouldn't, and if they never actually had an SLA they remain not having an SLA.

In regard to reporting, we purposely added two charts that work differently to accommodate for this:

• An elapsed time chart that displays the time metric values for all issues and a given time metric configuration. These values are always based on the current active definition and are recalculated if you change the definition. The idea is that this chart allows you to look at past/present performance, e.g. to evaluate where you would set the SLA target at in the first place. It also shows you how the team is currently doing in terms of elapsed time. Not the breached or not percentage is the question here, but the how long things take on average.

• An SLA breached/succeeded chart which is based an actual measured SLA outcomes. The values for this chart reflect the actual SLA outcomes stored against each issue. It tells you how the Service Desk team actually did at a given moment in time with the SLA configuration at that time. Recalculating past values would make this chart much less meaningful.

I hope this explains why Service Desk doesn't do SLA outcome recalculation.

Regards,

Michael

Edit: Nevermind

Could the JSD bugmaster step in here and assign this issue to a fix version or at least give some indication of Atlassian attitude towards it? It would seem to be a refutation of Atlassians claim that JSD applies retroactively, apparently believed to be a major selling feature.

We have put our plans to buy JSD on hold till we know that it will apply to our closed issues.
-David

Note that, as long as this bug remains, the conditions '"Time to resolution" = breached()' and '"Time to resolution" != breached()' are not exhaustive, since there will be issues that have neither breached nor not breached. This is a logical nightmare.
-David

Seems completely unbelievable! Did no one bother to test the claim that JSD applies retroactively to a project?
-David