How can I reference the value currently in a field within an Automation rule?

[Breonna Bowen]

Context: 

Within our workflow, we have a status we use "Waiting For Submitter" to indicate when the assignee needs additional details to resolve the issue. Since this is a blocker, want to exclude the time the tickets is in the status and not count against the team when the ticket is considered overdue. 

I'll attach photos of how we have the rule configured, note we have it isolated to a test ticket for now until we can figure this out. 

Problem: 

When the automation fires, we are able to successfully calculate the value for the field Time Waiting For Submitter (Days) when that field is empty. However, we run into issues when the field is not empty and requires an update. How can we reference or add to the value that is already in that field? Is this possible? Additionally, if there are any thoughts on how we can better capture and exclude the time the ticket is in that status, please let me know. 

Note: Smart value for the Else section is {{now.diff(issue.customfield_15041).abs.minutes.plus(issue.customfield_15070)}}/1440

[Breonna Bowen]

@Simmo 

The interesting issue now, the calculation works fine when a value is present and it's moved out of Waiting For Submitter once. If it's moved in and out of status multiple times it will calculate the most recent time, completely ignoring the value that's already there. 

• Update the second smart value from {#=}}{{issue.time waiting for submitter (days).value|0}} + {{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}} to {{#=}}{{issue.customfield_15070.value|0}} + {{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}}
• Reset the field at 6/26 16:30
• Transitioned to In Progress at 16:43
• Calculated 13/6/24 got 0.0090
• The automation calculated 0.0080
• Moved the status back to WFS and will move back to In Progress in the morning
• Move to In Progress on 6/26 at 8:13, automation calculated 1.642
• Calculated 2370/60/24 got 1.645
• 6/26 8:30 am move the ticket back WFS
• 6/26 16:59 ticket moved to In Progress
• I calculated 2.011 for the duration, the automation calculated .353
• The automation seemed to reference the second time the ticket was moved from WFS on 6/26 8:13am not 6/24 16:43pm.
• 6/29 8:13 moved to WFS
• 6/29 8:25 moved to In Progress
• I calculated 4.654, automation calculated .008
• Manually updated the TWFS field to reflect 4.654.
• Still calculated the most recent time today. 

[Rudy Holtkamp]

Could you elaborate on what kind of fields customfield_15070 and customfield_15041 are? For what are they used? When is a value set, what kind of values are set?

You do know that you can use an action component called 'log action' which you can use to debug your rule? This might help you to figure out where an when thing go wrong.

[Breonna Bowen]

Sorry, I, included those details in the screenshots, I'll reattach. How do I use the action components? 

[Rudy Holtkamp]

When you create/edit a rule you can choose different components.One of them is the 'new action' component. Click that and search for 'Log action'.

You can use texts and smart values (and computations) to debug.

[Breonna Bowen]

Thank you! @Rudy Holtkamp  I am getting the error shown above when attempting to add that component just an FYI. I would need to add {{#=}} at the beginning. 

[Breonna Bowen]

@Rudy Holtkamp  the log function still doesn't help me determine why it's not adding to the existing value in that field. It's still just calculating from the most recent time. 

[Rudy Holtkamp]

In the Activity > History tab of an issue you can exactly see what has changed and when.

Could you fill out this table 

Action	cf-15041	cf-15070	Time waiting for submitter
Initial values
transition waiting for submitter to In progress
...

And could you post the complete calculation you do in the automation rule for the time waiting for submitter (days) field?

[Simmo]

@Breonna Bowen , could you post a few screenshots of the rule as well so I can get the context of how it is looking now?

[Breonna Bowen]

Sure, here is where we are: 

For context:

customfield_15041 is the post function Support xt Waiting for Submitter.
customfield_15070 is the field Time Waiting For Submitter (Days).
customfield_15074 is the fields First Time In Waiting For Submitter.

Any we used: 

 {{#=}} {{ issue.customfield_15070.value|0 }} + {{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}}

OR 

 {{#=}}{{ issue.customfield_15070.abs.mintes }} + {{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}}

Anything prior to the plus sign calculated 0, everytime.

Then, we thought we should create a field capture the first time the ticket moved to waiting for submitter. So we implemented the following: 

If matches: 

Else-if Matches: 

We tried the following smart values: 

{{#=}}{{ issue.customfield_15074.abs.minutes }}/1440+{{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}}

{{#=}}{{ issue.customfield_15074.abs.minutes }}+{{ now.diff(issue.customfield_15041).abs.minutes }}/1440{{/}}

Each time we got 0 for anything before the plus sign. Everything after the plus sign we get a number like 0.001388888888888889. 

Then, we thought it could be the format, so we tried: 

{{now.diff(issue.customfield_15041).plus(issue.customfield_15074).abs.minutes}}/1440

Now we get the following error: Time Waiting For Submitter (Days): /1440

So it seems everything before the plus sign is completely disregarded. 

[Rudy Holtkamp]

Hi @Breonna Bowen ,

It is hard debugging this way. But I'll try.

I've written the rule it down from what I could see from the pictures and text:

1. if status changes from 'waiting for submitter' to  other statuses
2. and if project = TS and issue = TS-15489 
3. and if 'Time waiting for submitter (Days)' is empty
4. Then edit 'First time in waiting for submitter' by copying 'Support xt Waiting for     
    Submitter from <?> 
5. And edit 'Time Waiting for Submitter (Days)' by setting it to '{{now.diff(issue.customfield_15041).abs.minutes}}/1440' 
6. else if 'Time waiting for submitter (Days)' is not empty
7. then edit 'Time waiting for submitter (Days)' by setting it to '{{#=}}{{ issue.customfield_15070.abs.mintes }} + {{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}}' 

Remarks about the rule

1. Is there a destination status where this trigger should not run? Otherwise you can remove the 'To' statuses
2. issue = TS-15489 <=== for testing, I assume
4. Where is the value copied from? It is not clear in the image
5. I'm missing {{#=}} and {{/}} which means no calculation is done
7. Taken from your text in this thread, you misspelled minutes (mintes)

The last remark you make about:

{{now.diff(issue.customfield_15041).plus(issue.customfield_15074).abs.minutes}}/1440

This is also misspelled (missing the calculation start {{#=}} and end {{/}} and missing {{ before the issue.customfield_15074

{{#=}}{{now.diff(issue.customfield_15041).plus({{issue.customfield_15074).abs.minutes}}/1440 {{/}}

[Breonna Bowen]

1. There are two statuses that it should not run on. 

2. Correct, we are trying to isolate this work until we know it's working properly. 

4. There are a number of post functions we have in place on the assigned workflow to capture the time and date a ticket is transitioned to a status. So the field copied is Support xt Waiting for Submitter and it's copied to 'First time in waiting for submitter'. 

6 and 7. That makes sense. 

I'm going to go back to the original set-up and ensure the log functions are in place. I'll follow-up with the calculations. 

[Breonna Bowen]

@Rudy Holtkamp 

Action	cf-15041	cf-15070	Time waiting for submitter
first transition waiting for submitter to In progress	2020/07/02 9:15 AM	None	0.002
second transition waiting for submitter to In progress	2020/07/02 9:19 AM	0.002	0.003

Note: 

Times transitioned to in progress: 

1. 2020/07/02 9:18 AM

2. 2020/07/02 9:24 AM

I reverted back to this calculation in the else-if matches section: 

{{#=}}{{issue.customfield_15070.value|0}}+{{now.diff(issue.customfield_15041).abs.minutes}}/1440 {{/}}

 Using the logging function, I noticed the following on the second: 

Post function value: {{#=}}{{now.diff(issue.customfield_15041).abs.minutes}}/1440{{/}} I get  0.003472222222222222

Post function value: {{#=}}{{issue.customfield_15070.value|0}} {{/}} I get Post function value: 0

So the rule is completely disregarding everything before the plus sign. 

[Simmo]

So it sounds like the smart value is not getting the correct value out of customfield_15070. Could you look at the rest representation of an issue with it set and provide the details of it? Eg https://xxxxx.atlassian.net/rest/api/2/issue/BIO-14?expand=schema would get the rest representation for bio-14.

You're then looking for your field, customfield_15070. Can you paste in what we see? as well as the entry that shows what type it is?

[Danyal Iqbal]

This is a bad practice. Don't do it.

[Rudy Holtkamp]

Use something like this in the edit action.

{{=}}{{issue.time waiting for submitter (days).value}} + <your calculation> {{/}}

[Breonna Bowen]

@Danyal Iqbal  can you elaborate on why? 

[Breonna Bowen]

@Rudy Holtkamp got the following error: 

Error parsing template: Invalid delimiter string: }} {{issue.time waiting for submitter(days).value}} + {{now.diff(issue.customfield_15041).abs.minutes}} {{/}}

[Rudy Holtkamp]

@Breonna Bowen , sorry you should start with {{#=}} instead of {{=}}.

For more details about math expressions take a look here

[Simmo]

And use a default value for when the field is empty. So taking the above suggestions, it would look something like:

{{#=}}{{issue.time waiting for submitter (days).value|0}} + <your calculation> {{/}}

I added the |0 which will default to zero if the field is empty. If you don't do that then you'll get an expression error.

[Breonna Bowen]

That worked! Thank you!