I have here a use case that it's an interesting case of using the Rule Automation and how we solve it but also we are facing a synchronization issues!
In our case we have an Epics that are requirements and those Epics have a link "Depend on" to Stories (also those Epics might children, child to, other Epics/parents but let's leave that for a moment).
Our goal to synchronize the Fix Version of these Stories with their Epics, in a way that when we change Story's Fix Version the Fix Version should propagate to all the related Epic. Note that we don't add the new Version to the Epics, we need to replace it in the list of Fix Versions for the each Epic (each Epic has all the Fix Version of their stories and of course Versions can be shared): for example if in a Story we deleted the Fix Version, this Version should be deleted from the Epics unless it's used in other Stories of course... etc. So the solution is to reset the Epic's version and rebuild/collect the versions from the Stories starting with the "new" changed Story.
The way I implemented the solution is Rule #1 when a Fix Version is changed in a Story, it branch out for the Epics and for each one reset the Fix Version of the Epic with only that particular changed Version (not adding).
Then another Rule #2 triggered when the Fix Version is changed for the Epic, and in this Rule the Epic branch out for each of its Stories (in a condition that it's not that same Story that was changed in first place, because the Epic already has the Version) and reset coms custom field in the Story and change it with the trigger issue key (Epic key #).
Rule #3 is triggered when that custom field is changed, in a condition it's not empty it will branch out with JQL on that custom field and fetch the Epic to "add" the trigger issue (Story) Fix Version to the Epic's Fix Version.
This work perfectly in many cases, until we test it in some hierarchies when we have same Stories are linked to different Epics and the race and order of things ruin the final resutl.
Since branching out from the Epic to their linked Stories to update the custom field happens on the same time (we checked on the log and comments), so we have rules that executed in parallel and they update the same custom field of the same Story!
I think this cause issues to update the list of versions correctly into the Epics. So we have consistencies and sometimes although we see from the comments that the Epic # is retrieved and the correct Story's version should be added, IT'S NOT ADDED and the Epic missing 1 or 2 versions.
I hope I was clear in my explanation, but if not clear I can clear and send screenshots from my rules.
The way I am thinking to solve this it to add safe-guards when executing the branching so we have some order on rule executions (Rule #3) when executed on the same Story:
Rule Execution_1 of Epic_1->Story_X and Rule Execution_2 of Epic_2->Story X is run in parallel, better that Rule_Execution_2 delayed or executed after Rule_Execution_1.
This is a limitation because of the solution I chose to use custom field in a Story, I couldn't find other solution to store some info and re-use and also can trigger a rule.
Hello Community! We thoroughly enjoyed this just-for-fun conversation in the Jira Admin Group about what it's like to be a Jira Admin. For #JiraJuly, our talented designers created these graphics t...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events