How to calculate the resolution time as a difference between 2 fields using Jira Automation Rules?
Asked by Ionascu Irina:

Hello,

I would like to calculate the the difference between the Resolution time and the Created time in order to see in how much time the ticket was solved. I have defined a rule in Jira Automation Rules with the following expression :

{{issue.created.diff(issue.resolved).hours}}

I have also created a custom field where this calculation shall be shown in the ticket. The custom field was created as number and it works.

But I have a question cause I cannot figure this out : when I reopen a ticket (which was previously Solved) for a rework, and afterwards I put it again in Resolved, it is not clear for me if it's summing all the time the ticket was in Open/Progress or not. Cause what we would need is to have the sum of the total time the ticket was in progress before passing to Resolved.

Thanks,

Irina


Answers:
author: Dirk Ronsmans
body: Hi [@Ionascu Irina](/t5/user/viewprofilepage/user-id/3521385) ,

I couldn't find any details about the {{issue.resolved}} smartvalue so I did a quick test.

I Resolved an issue, re-opened it and Resolved it again.

When i comment on the issue with the {{issue.resolved}} value I can see the following below.

![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/111440i274ABB8818F0B5B1/image-size/large?v=v2&px=999 "image.png")

so yes, time was added!

The only questions for me is how does it see it as resolved, I would assume when the "Resolution" was set so just make sure when you re-open the issue that the Resolution is cleared. (which is best practice anyway)

comments: author: Ionascu Irina
body: Hi [@Dirk Ronsmans](/t5/user/viewprofilepage/user-id/124602) ,

Thanks for the quick answer! Indeed, I also did a few more tests, and I understood where the problem might be with this summing... This formula always takes into account the creation date and the last Resolved date. Meaning, that for example, if I have a ticket set as Resolved now, with Resolution time 12 minutes, supposing I will reopen it after 30 minutes to do some rework, and keep it open for another 30 minutes, the new resolution time will be 72 minutes, which is not quite correct. Because the counter shouldn't count the time between Resolve until Reopen, meaning, it should calculate only the time between In Progress to Resolved, so it should be 12 minutes from the first iteration plus another 30 minutes from the second iteration, a total of 42 minutes and ignore the 30 minutes since the ticket was Resolved until I have reopened it.

Do you know how we can solve this? I assume it must be a more complicated formula..


author: Dirk Ronsmans
body: Hi [@Ionascu Irina](/t5/user/viewprofilepage/user-id/3521385) ,

I see what you're trying to do but I fear this might not be possible without either an app or some more automation work..

It would basically mean going through the history and calculating how long the issue was in a specific status.

As you are using server a colleague of mine highly recommends the following app:

[https://marketplace.atlassian.com/apps/1220908/time-in-status-field-timer-stopwatch-sla?hosting=server\&tab=overview](https://marketplace.atlassian.com/apps/1220908/time-in-status-field-timer-stopwatch-sla?hosting=server&tab=overview)

It's a free one so giving it a try shouldn't be a bad thing :)

Otherwise I fear you'll have to make some more custom fields and through automation calculate/write back the time for the statusses. (but that seems just what this app does)

Would you be open to using another app? Or is this something that "has" to be done using automation?


author: Ionascu Irina
body: Thanks [@Dirk Ronsmans](/t5/user/viewprofilepage/user-id/124602) ! I will try with this plugin as it is free. I am open to use apps if are free also, I started doing some thing with the Automation Rules and this is why I wanted to do it with this method, but even better if we have something that already does it


author: Dirk Ronsmans
body: Great!

I fully get it and if this free app does what you need i to do all the better!

Should it for some reason be discontinued in the future you can always revisit the use case then and who knows maybe another solution exists by then!


Tags: server