Automation: trying to understand JQL conditions when used in rule

[Louise Baker]

I have an automation wherein if the Priority changes, I want it to update the sprint.

If its in one of p0/1/2, it should go in the active sprint, p3, in a later sprint, and p4 in yet a different sprint.

I want to check to make sure the sprint I'm trying to change it to isn't already set.
In order to do this, I'm using the IF/ELSE branch, and using the "all of these conditions met"

However, I can't wrap my brain around the difference between smart value and JQL

In my workflow below, the ifElse w/ Prioirty 3 will not punch if the priority field is updated to P3. In my audit log, I'm getting:

The following work items did not match the condition:

• The work item didn't match the specified JQL.
• The chosen rule actor doesn't have permissions (or work item security level permissions) to view the work item.
• the work item was deleted or wasn't indexed by Jira yet (in rare circumstances)

We recommend using the 'Issue fields condition' for more consistent results.

 It has the proper permissions, so it must be that I entered in the JQL wrong. So.. am I supposed to use smart values (like I attempted in the FIRST IF block?
Or.. what am I doing wrong?

[Bill Sheboy · Accepted solution]

Hi @Louise Baker 

First thing, Atlassian is currently recovering from an automation-impacting incident and that may be doing more than just delaying rules.  Please look here to monitor progress: https://jira-software.status.atlassian.com/incidents/8l2pc9p1fr04

And...

For your first JQL condition on priority, you use the smart value for priority on the left side of the expression, which will likely fail trying to compare a number to a field (which JQL cannot do).  Please try using just the field name:

priority IN ( "Priority 0", "Priority 1", "Priority 2" )

The rule already has the issue in scope, and so it is only checking that specific issue with the JQL.

Kind regards,
Bill

[Louise Baker]

Thanks for the info about the automation incident, mabye thats it.
My question was "should I be attempting like my first if block using smart value, or should I be doing it like the second block".

So your answer then is that it SHOULD NOT be using smart value, and it SHOULD be like the second attempt I had.

It is failing when I do it just like that with the error I posted.

So, do I have something else wrong, do you think? I can't quite determine what, it seems pretty straightforward :(

[Louise Baker]

As in, if the issue was in priority 3 and NOT in the sprint (so, the condiitons are met) it's "succeeding" with no change made with the error I listed, rather than performing the "then" step I provide.

[Bill Sheboy]

Would you please post an image of your current, complete rule in a single image (for continuity) and another of the audit log details showing the rule execution (with all the areas at the right side expanded)?  Those may help to explain what you are observing.

As an aside: I rarely use the Related Issues, JQL Condition because the automation engine adds undocumented things to the JQL behind the scenes. And so troubleshooting is more difficult.  For example, the Branch on JQL definitely adds any trigger issues as exclusions to the expression.

Instead, I often use the Lookup Issues action with my explicit JQL and then test the result count using the Smart Values Condition.

[Louise Baker]

Yes, attached! It's quite long, sorry!

Long and short, the goal is this:

1. If the priority changed, make sure it's in the appropriate sprint.

• Priority 0 / 1 / 2 map to Active Sprint
• Priority 3 maps to a next sprint, with the value of 50
• Priority 4 maps to a next sprint, with the value of 51
• "Not Prioritized" priority should have the sprint emptied, if it isn't already empty.

2. If sprint is already appropriate, don't change it.

In the example, you can see I have a log action set up. It's reporting that I did the action, and I am in the group Product Management. Additionally, I am an admin on Jira and on the project, so I should have sufficient permissiosn.
The field updated was priority. It went to Priority 4. The sprint was blank. That means it should have hit the second else-if block. You can see that it passed one, but then I get the error that it didn't match the condition. No change was made to the ticket.

[Louise Baker]

I also truly appreciate your help :)

[Bill Sheboy]

Let's try a simple change first:

Anywhere you are testing for the sprint not equaling something, consider if it could also be empty.  And so for the first condition with JQL, that should be

sprint NOT IN openSprints() OR sprint IS EMPTY

Please consider your other conditions to decide if that clause applies when comparing sprint not equal to 50 (or 51).

I recommend pausing to create a logic-table to identify the test cases (for sprint, priority, and permissions) to ensure you test all possible cases.

Finally, at the very top of the rule, do you want an additional condition to check if a work item is not completed?  That will prevent any accidental assignments to sprint if someone mistakenly changes a completed work item.

[Louise Baker]

Thank you IMMENSELY. You are WONDERFUL.

You also answered my immediate question, which was, does the JQL need to use smart value? The answer is no.

Thank you so very much.

[Louise Baker]

BTW, everything seems to be calculating correctly now. Whether it was resolution of something gunked up, or the "empty" sprint part, all OK. I truly appreciate you :)

[Bill Sheboy]

Awesome; I am glad to learn that helped!

[Ana Livia Rocha Silva]

Hi @Louise Baker 

Have you tried just using the 'Work item fields condition'? Did you run into the same problem?

Regards,

Ana 

[Louise Baker]

I did try this, but it won't let me have granularity on Sprint. I can either do "Not in active sprint" or "not in a sprint", but I need to check against other sprint value later on. THank you though!