Time to resolution copy to Due date minus one day

[Bo Schlichting]

Dear all

I am trying to set up a automatization in cloud, so that certain tickets are the due date field updated with the Time to resolution minus one business day.

Example, we have a Time to resolution via the automatic SLA, which is 7th at 08:12.

I then want the Due date field to be updated with the date the 6th.

This is to ensure that the developers get their fix in place the day before the SLA runs out, so support have time to react and interact with the customer.

I was hoping to use the Edit issue like shown below

Thanks

Bo

[Stefan Salzl · Accepted solution]

Hi @Bo Schlichting 

huuuuuu......that was tricky. But the trickier the more fun trying to solve ;)

Found out that time to resolution is stored in objects. 

so printing the smart value of that field looks like:

TimeToResolution: SlaCycleBean{startTime=SlaDateTimeBean{iso8601=Tue Jun 28 08:11:16 UTC 2022, jira=Tue Jun 28 08:11:16 UTC 2022, friendly='28/Jun/22 10:11 AM', epochMillis=1656403876502}, breachTime=SlaDateTimeBean{iso8601=Wed Jun 29 08:11:16 UTC 2022, jira=Wed Jun 29 08:11:16 UTC 2022, friendly='29/Jun/22 10:11 AM', epochMillis=1656490276502}, breachTime=null, breached=true, paused=false, withinCalendarHours=true, goalDuration=SlaTime{millis=28800000, friendly='8h'}, elapsedTime=SlaTime{millis=5117134543, friendly='1,421h 25m'}, remainingTime=SlaTime{millis=-5088334543, friendly='-1,413h 25m'}}

So I got through this objects and could get to your expected result (i guess). (--> please make sure to test this. this is something new for me too).

 Please try to set your due date to the following:

{{issue.customfield_10038.ongoingCycle.breachTime.jira.minusDays(1)}}

Best
Stefan

[Stefan Salzl]

@Bo Schlichting 

furthermore: check the correct field_ID in your system ;) not 100% sure if this is always the same.

Best
Stefan

[Bo Schlichting]

Hi Stefan

Thanks for the effort :)

I tried with the suggestion and did not get any result. :(

So to figure out this, I need a bit more detailed description on what to do and most important where. ;)

You write:

"Found out that time to resolution is stored in objects. 

so printing the smart value of that field looks like:"

But does that mean that I should do anything regarding this?

Then you suggest that:

"check the correct field_ID in your system ;)"

Where do I do that?

Thanks :)

Bo

[Stefan Salzl]

Hi @Bo Schlichting 

Could you please share screenshots of your current automation rule as well as from the audit log. Is there any error shown?

Further question:

Does the rule operate within the same project or would you like to set the due date in an issue within another project? (I´m asking becase Time to resolution is a ServiceManagement related field and in your description you wrote the developer should see the earlier due date. So I assumed it could be you would like to set the due date in another project where developers are working in).
If so: did you configure your rule as a global or multi-project rule? (this is set in the rule´s details).

regarding your question:

"check the correct field_ID in your system ;)"

Where do I do that?

The following page is showing how to retrieve the JSON of your issue:

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

You can search there for your field (by name) and you will find the name and the customfield_ID. this will look similar to the following:

Best
Stefan

[Stefan Salzl]

Hi @Bo Schlichting 

just tried it with the field name and it worked in my system. You could try the following (case sensitive):

{{issue.Time to resolution.ongoingCycle.breachTime.jira.minusDays(1)}}

For test reasons I always add a "log action" action in my automation rule to see if my smart value works. this looks as follows in my automation rule:

So if my smart value resolves correctly it will write the result in the audit log.

Best
Stefan

[Bo Schlichting]

Hi Stefan

Thanks for your continuous effort to help me :)

I will try to answer all you questions and show the logs etc.

First, when I try to reach the field ID, did I try different options like:

https://usemover.atlassian.net/rest/api/2/issue/Time To Resolution?expand=names

But get this feedback:

{"errorMessages":["Issue does not exist or you do not have permission to see it."],"errors":{}}

Same if I try and remove the " " (Space) in Time To Resolution.

I try to set Due Date in this project, but got the same field active in the developer project. I then have another automatization to update due date on linked issues, which works as it should. ;)

Therefore do I "just" need to set due date in the ticket to SLA date- one business day.

When I add the log action, can I now see the following:

[Bo Schlichting]

I now changed the priority to tricker another SLA value:

SO, it seems that the due date is updated, but with the SLA value of the previous Priority.

I have tried to just do a text update of the ticket and the Due date is not updated.

Best regards,

Bo

[Stefan Salzl]

Hi @Bo Schlichting 

https://usemover.atlassian.net/rest/api/2/issue/Time To Resolution?expand=names

But get this feedback:

{"errorMessages":["Issue does not exist or you do not have permission to see it."],"errors":{}}

Same if I try and remove the " " (Space) in Time To Resolution.

to call the issue endpoint of the api this needs the issue key at the end (as described in the documentation). So instead of Time To Resolution fill in your issue key.

Please send the current state of your automation rule as well as (if possible) a screenshot of your issue. Without knowing any details of your configuration it´s hard to analyze any problem as the output of your audit log looks correct and the smart value I sent you worked perfectly in my tests. If you tried this solution please make sure you copied it correctly as automation for jira and smart values are case sensitive.

Best
Stefan

[Bo Schlichting]

Hi Stefan

Thanks for cutting it out in pieces for me. :)

customfield_10541 : Time to resolution

The Rule is:

Most of the rules will be removed when we are live, it is just to not disturb the production environment too much ;)

Due date rule:

{{issue.Time to resolution.ongoingCycle.breachTime.jira.minusBusinessDays(1)}}

If I instead uses:

{{issue.customfield_10541.ongoingCycle.breachTime.jira.minusBusinessDays(1)}}

Do I get exactly the same problem that it uses the SLA value for the previous priority as calculation rule. :( 

Best regards

Bo

[Stefan Salzl]

Hi @Bo Schlichting 

ok let‘s wrap this up:

The rule should fire/be triggered when the priority changes (as SLA is connected to priority)? And if so it should (of course) return the SLA of the current (changed_TO) priority? Is that correct?

So does the rule always return the value of the previous priority? Or only if you use the ‚customfield_xxx‘ ?? is there a difference between using the fieldName vs. using the fieldID?

furthermore:

Could you also send the SLA definition/priority SLAs?

Best
Stedan

[Bo Schlichting]

Hi Stefan

The rule should fire/be triggered when the priority changes (as SLA is connected to priority)?   YES

And if so it should (of course) return the SLA of the current (changed_TO) priority? YES

Is that correct? YES that is correct

So does the rule always return the value of the previous priority? Yes. it seems like that

Or only if you use the ‚customfield_xxx‘ ?? No

is there a difference between using the fieldName vs. using the fieldID? No

furthermore:

Could you also send the SLA definition/priority SLAs?

Time to resolution

Workday calendar is 24/5, so it counts 24 hours per day except weekends and holidays.

Best regards and thanks

Bo

[Stefan Salzl]

Hi @Bo Schlichting 

got your point and got stuck at the same point. Unfortunately and obviously it‘s technically built that the change of the field „Time to resolve“ fires when the action of priority change is completly done therefore it‘s not detected correctly and always refers to thw previous sla. Also tried with several branches and re-fetch action as i thought it might be a timing problem but didn‘t solve this either.

I there is even the possibility to choose the „Time for resolution“ field to be in the field change trigger (as this field IS changed when priority gets changed) —> unfurtunately the automation doesn‘t even trigger in this case (which I peronally find pretty suspicious). 

I posted this to atlssian team to look into it.

Sorry for not being able to offer a propper solution here :-/

Best
Stefan

[Bo Schlichting]

Hi Stefan.

Thanks for your dedicated effort.

I will continue to see if I somehow can make this work as it would help us keep the SLA.

I will update if I find a solution.

Kindly

Bo

[Stefan Salzl]

Hi @Bo Schlichting 

I couldn´t stop trying and found out it´s really a timing problem. With adding several "re-fetch" actions and 2 "current issue" branches it worked.

So I´m not 100% satisfied with it but if the rule can be delayed in any way (like re-fetch, branching, calling a jql or a webservice just for the reason of slowing down the processing) it should deliver the correct value. 

My rule looks as follows:

Best
Stefan

[Bo Schlichting]

Hi Stefan

Mad world we live in... ;)

But yes this works in most cases, so I have added more Re-fetch actions, so that it great. :D

Thanks for the continuous effort to resolve this.

Best regards

Bo

[Bo Schlichting]

Hmmm.. one thing I then noticed is that my other automatization, which then copies the Due date to the tech case is not working as it is not catching the change is seems. :(

I will play a bit more with that and perhaps create another ticket for that.