I'm using Jira cloud and have 2 projects with some linked work items.
Both projects have the same settings with the same permissions.
I have an automation rule to synchronize status between 2 linked work items, which works as intended.
In one of the projects, I have another automation rule which can trigger a status change on its work items. I do want the linked work items to be synchronized, so I checked the tick box to allow automation rules to trigger the status change synch rule to work.
Now I have an issue that the synchronization of the linked work item, triggers this same rule on the linked item as well. This would result in an infinite loop if it wasn't for an error because automation cannot transition to the status it already has (thank you workflow restriction).
To avoid this resynch, I tried to add an if statement in the branch, but for some reason the automation will always pass on that if statement and try to update the status for a 2nd time.
First of all: I thought rules should not be able to trigger themselves so why does the status change of the first run through the rule, trigger itself again? Is this because it is being triggered on a different work item?
2nd: why does my if statement not stop the 2nd run through the rule and still attempt to transition again?
Dag @Jan Nolens
In your automation, you have a non-descript trigger followed by a branch that is allowed to change the status for both “is duplicate” and “duplicates” conditions. That in itself generates the infinite loop if the automation is allowed to start itself.
How to avoid this from happening?
You should construct two automations, nearly identical, yet each with its own singular branch: so one for “is duplicate”, and the other for “duplicates”.
Only one of these automations should be set to be able to be triggered by other automations.
This means that you should choose which of the branches should override the other, the automation with the overridable branch should be set to “can be triggered by other automations”
Kind regards,
Dick
Dag @Dick
That could indeed work to avoid the infinite loop.
My automation trigger is 1 directional, however I would need to make sure the duplicate link is always in the same direction as well.
This definitely something I should look into.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Jan Nolens , remember that execution of branches is done in parallel by Jira’s automation engine. There’s no way of telling the order in which they are executed nor finish. The limbo state resulting can in some cases be avoided by either separating them from each other, or by using a re-fetch of the current work item. As you’re dealing with multiple work items, I went for the former solution.
Kind regards,
Dick
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Jan Nolens
Welcome to the Atlassian community.
Addressing your "first of all", if you check the box to allow a rule to be triggered by action taken by another rule, then it can be triggered by the actions of any rule. So the action of rule A can trigger rule A. This is an intentional feature to support recursive rule execution.
Regarding why the IF statement doesn't work as expected:
1. Please provide screen images showing the results in the rule execution Audit Log.
2. Add Log Actions to your rule to log the value of the Status of the linked issue and the trigger issue immediately before the IF statement. That will help validate what values are being compared in the IF condition.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the reply.
It seems the IF statement I used is not behaving as I thought it would.
I had added a smart value if statement and that one seems to trigger correctly
It would probably be helpful to understand why these 2 if statements are not the same, however I can work with this
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Jan Nolens
Can you provide a screen image showing the details of the "Status does not equal" component?
Can you add the Log actions that I recommended, placing them before the "Status does not equal" component, run the rule again, and share screen images showing all the details from the Audit Log for execution of the rule?
What are the project Types of the projects in scope for this rule? Get that information from the View All Projects page under the Projects menu.
Can you check to see if there is a Global custom field named Status? There should not be, but if there is that could confuse the Automation Rule.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Both projects involved are company managed software projects and they share the same configurations: issue types, schemes, workflows, fields....
Log when status field on both work items are different:
Log when both items are the same (runs automatically again because last action of previous run, makes it run again)
Config of the work item field condition check which passes in both runs above
Automation rule:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for that additional information.
Would you consider doing another test removing the smart value compare to see what is reported?
As it stands now the work Items Field condition and the Smart value condition are getting the same results. I would like to see if removing the smart value condition will result in the problem occuring again. If it does then I would suspect a timing issue where the rule is running before the data is truly saved in the database.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
in the case where the status values are different, both conditions show a different result.
The work item field condition shows it passes, the smart values condition says it does not pass...
If I remove the smart value comparison I will get an error because the next step is to transition the card which it cant do as the workflow does not allow transition to the same status value.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for that additional information.
I have recreated the scenario in my own environment and am seeing the same results that you see.
I happen to be using a Free Jira Cloud subscription. What type of subscription are you using?
I'm asking other community members to take a look at this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We have a company license. Don't know the details of it myself.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Let me see if I can sum up this scenario.
1. There is an Automation rule that executes issues transitions.
2. There is a second Automation rule that reacts to issue transitions
- This rule needs to react to both manual transitions and transitions executed by other automation rules.
- This rule needs to react to all transitions (for issues in the specified project scope), not just transitions to or from a subset of statuses.
- This rule will set the status of issues linked to the rule trigger issue to the status of the rule trigger issue.
- This rule should execute that synchronization only if the linked issue and rule trigger issue are not already set to the same status
3. Because the second rule has to react to transitions made by other automation rules it needs to have the option enabled to be triggered by Automation rules.
4. Because of #3, the transition being executed within the second rule causes the second rule to be triggered again.
And the observed behaviour is:
When #4 occurs (the second rule is triggered again by the transition that it executes) the Work Items Field Condition used within the branch to compare the Status of the linked issue to the Status of the Trigger issue is not detecting that the Statuses are the same. But the Advanced Compare condition does detect that the statuses are the same.
We know that the rule will work as intended when the Advanced Compare is used.
So the question is:
Why does the Work Items Field Condition get a different result than the Advanced Compare in this scenario?
Have I summed it up correctly?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That sounds right to me.
Yes, I can use the advanced compare so that's fine... But the fact the work item field compare is not behaving as expected makes me think I misunderstand it's functionality...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't think you have misunderstood the functionality. I would expect it to be able to tell that the values were the same, in this scenario.
There could be some weird timing issue with the rule calling itself for the same pair of issue it was just operating on.
One other thing I can think of to try is to add a Re-fetch Issue Data action right after the trigger, and one right as the first thing within the Branch.
One last thing I can think of to check would be the Post Functions for the workflow transition(s). Maybe there is something odd about the Post Functions that would become evident if we knew what they were.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What are you referring to when you say "this"?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Trudy Claspill Fields of a modified work item display only the modified content correctly after a re-fetch. The action of modifying a field’s value is done in the database, not the work item “copy” that is used inside the automation. The modified field value needs to be re-fetched to work with it.
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.