Dear All,
We have two teams sharing the same Jira project: a team of developers (DEV) and a team of testers (QA). Each team has its own tasks and they run parallel sprints. The idea is that while the DEV team works on its current tasks, the QA team tests the tasks completed by the DEV team in the previous sprint. In order to do that, each time a DEV sprint ends we have to manually create a task for each user story in the DEV sprint which is in the DONE state. Moreover, in order to keep things organized, each new task must be linked with the original user story.
We decided to take advantage of the Jira automation capabilities and automatize this whole process.
We created the following rule in a dummy project and tested it.
The idea is simple:
It took me a while to design the rule the way it is now. At the beginning I thought that I could simply use the same clone-issue command to update the link as well, but apparently this cannot be done: first you have to create the new task and then link to the previous one.
I thought of using nested branch because I needed to refer to each issue in the "issues-in-sprint" branch when creating the link.
Well, the rule is working just fine in the dummy project, so I decided to create a similar rule in our main project. Today I tried to do that but I soon found that it was impossible: I could not nest the two branches.
I started looking around for a solution and for my surprise I discover that braches cannot be nested.
I'm now facing two dilemmas:
I hope someone could help me finding a solution to this mystery...
Hi @Matteo Cristiani -- Welcome to the Atlassian Community!
Apologies in advance for the long answer...
For your first question, I do not believe nesting branches is supported. I have seen posts where people dragged a completed component (branch/condition/action) from one area of a rule to another, allowing things which are not supposed to work/be supported. Did you perhaps do that? I tried it myself and was unable to do so with Jira Cloud.
I recommend working your site admin to submit this to Atlassian Support to learn how this was possible: https://support.atlassian.com/contact/#/
For your second question: the work-around for this nesting limitation is to use another field/comment to hold the key for the issue to which you want to link...and then add the link outside of the branch in another rule.
You would think this would be possible in one rule...
But branched issues process asynchronously and so there is no guarantee the first branch will complete before the second one starts AND finishes.
Instead create one rule to clone the issues, create a second rule to detect the new issues and then add the links. The setting of "Allow Rule Trigger" should be enabled for the second rule so one can fire off the other.
Kind regards,
Bill
Hi @Bill Sheboy,
Thank you for your detailed answer.
Indeed the first time I created the rule I dragged a complete component (branch + action) into the other brach you can see in my picture. This is exactly the same thing I tried to do when I created the second rule, but for some reason it did not work: maybe some other condition must be fullfilled for this to work. I'll inform my system admin.
I will definitely try to implement your suggestion and use two independent rules, but first I have to contact my system admin to create the new field required to keep trace of the original user story. I will let you my progress.
Thank you for your help!
Best Regards,
Matteo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One work-around in case you cannot add the custom field (i.e. Site Admins try not to cause a lot of custom field sprawling...) is to modify rule #1 add a comment with an indicator-note, date/time stamp, and the key...modify rule #2 to detect the new comment with a condition on the indicator-note.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I finally managed to implement the wanted functionality without using a custom field.
Here goes the solution.
First I created the following rule:
This rule is triggered when a sprint is completed and all the User Stories in the "Done" state are cloned. As you can see, the summary is set to "Testing {{issue.key}} - {{issue.summary}}".
The second rule is the following:
The rule is triggered each time a new issue is created. The option "Check to allow other rule..." is enabled, thus allowing the rule "Testing tasks 2" to be triggered by the issue creations which take place within "Testing task 1".
"Testing tasks 2" first checks if the summary of the newly created issue starts with "Testing", thus selecting only the tasks created by the previous rule. Using advance issue fields editing, the original issue key is extracted from the issue summary and assigned a proper link is created.
Thank you again @Bill Sheboy!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well done, @Matteo Cristiani
One more thing of note: sometimes when Created Issue triggers it occurs so quickly that all of the data is not present yet. The impact is conditions could fail to match on the issue (because the fields the rule sees are empty).
The work-around is to add a Re-fetch action immediately after the trigger to slow down the rule and re-load the data before more processing.
I hope you have a great day!
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.