We have a need to keep track of how many days each developer has spent in an operational role supporting our support team versus how many days they have spent in a project role developing new functionality. The operational role is known as Primary Responder or P1
I have created a new card type, known as "People". I have created the following custom fields:
10131 P1 Days
10132 Joined Team
10133 Previous Team Days
10134 Previous Team Join Date
10137 previous P1 days
The automation rule looks like this:
1. When people card transitioned from x to y (statuses that I'm not delineating in this post)
2. and the Issue type = People
3. Then: Edit issue fields "Previous Team Days":
{{issue.customField_10132.diff(issue.customField_10134)days}}
Description: Joined team date minus previous join team date in days
4. AND Edit issue fields "Previous P1 Days":
{{customField_10131}}
Description: Copy P1 days to Previous P1 days
5. AND Edit issue fields "P1 Days":
{{customField_10133}}+{{customField_10137}}
Description: Add Previous Team days to Previous P1 days
Now, something very strange happens. It works every other time, and fails every other time. However, there is an error message every time that says:
Failed to get value for issue.customField_10132.diff(issue.customField_10134)days: {{issue.customField_10132.diff(issue.customField_10134)days}}
So for testing purposes, I set the following:
Joined Team: 2021/04/20
Previous Team Join Date: 2021/04/18
Previous Team Days: 2
Previous P1 Days: 2
P1 Days: 2
So then, I would expect the progression to be:
2 2 2 (initial state)
2 + 2 = 4 (this works)
2 + 4 = 6 (instead I get 2 4 4)
On next move i get 2 + 4 = 6
Next move I expect 2 + 6 = 8, but I get 2 6 6.
So confused.
So I'm going to answer my own question, because I ended up figuring it out. Just in case someone runs into this in the future.
This is a combination of two problems:
1. When running a rule, it appears that it runs the rule based on what the value of a field was when you started running the rule, not its value based on previous steps in the rule. This can be solved with the action "Re-fetch issue data".
2. This one is frustrating to me, but it appears that when you use
{{issue.datefield.diff(issue.datefield)days}}
it does not return the result as a number. I cannot figure out how to force this directly. However, I added another field called "Previous team days text" and made it a text field. Then I added a step that has:
{{#=}}{{issue.customField}}{{/}}
which converts the text in the text field to a number.
It seems that there should be a more direct way to do this, but after hours of messing with this yesterday I managed to get it working this morning.
Yup, that edit/use field behavior in rules can be solved with the re-fetch action...although it slows the rule quite a bit. When possible, you may also store a calculated value in a Created Variable when you plan to re-use later in the rule.
Also consider using default value handling when you need a numeric. This can address any null values in your fields. For example: {{issue.myField|0}}
Best regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Bill Sheboy .... I'll try the created variable approach. This rule I have is a HUGE Rube Goldberg machine.... the rule takes around 45 seconds to run. I ended up having to refetch data 3 times, which is probably most of the length of the rule.
This rule will only get run a couple of times a month, so in this case it's not a huge problem, but I anticipate doing this kind of thing more so a better approach is needed long term.
Thanks for the help.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree, and... you may want to read about the service execution limits and performance recommendations. When debugging a longer running rule, you could start piling up execution time and cause a service breach. Web requests, branches, re-fetches, and chained-rules are the usual suspects for time usage, so using something like Created Variable can help with a couple of those.
https://support.atlassian.com/jira-software-cloud/docs/what-are-service-limits/
https://support.atlassian.com/jira-software-cloud/docs/optimize-your-rules/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Jason,
Thanks !
That has solved my issues :
1. When running a rule, it appears that it runs the rule based on what the value of a field was when you started running the rule, not its value based on previous steps in the rule. This can be solved with the action "Re-fetch issue data".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jason,
Not sure this contributes to the problem with just a cursory glance, but I noticed this in Step 4:
{{customField_10131}}
It probably should be
{{issue.customField_10131}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
got it.... I'll change that over. I was wondering about that because I saw it both ways, and wasn't sure which was correct.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.