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: * The rule is executed when a sprint is completed * The actions are performed on all the issues in the sprint * We first check that the issue is in the DONE state and that its a User story * We then clone the issue. The cloned issue is a "Task" and not an "User story" * We then link the newly created issue to the original issue 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: * How could I create the original automation a few days ago if branch nesting is not allowed? How could it work? * If branch nesting is not allowed, how could I rewrite the original automation without this feature? I hope someone could help me finding a solution to this mystery...

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Create test tasks from user stories - automation branch nesting

Matteo Cristiani

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:

The rule is executed when a sprint is completed
The actions are performed on all the issues in the sprint
We first check that the issue is in the DONE state and that its a User story
We then clone the issue. The cloned issue is a "Task" and not an "User story"
We then link the newly created issue to the original issue

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:

How could I create the original automation a few days ago if branch nesting is not allowed? How could it work?
If branch nesting is not allowed, how could I rewrite the original automation without this feature?

I hope someone could help me finding a solution to this mystery...

Accepted answers

Bill Sheboy

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...

trigger: sprint completed
branch: on issues in sprint
- condition: status is done
- condition: issue type is Story
- action: clone issue...saving the {{issue.key}} somewhere in the cloned issue's fields
branch: on created issues
- action: link issue using the saved key information

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

All comments

Bill Sheboy

Hi @Matteo Cristiani -- Welcome to the Atlassian Community!

Apologies in advance for the long answer...

I recommend working your site admin to submit this to Atlassian Support to learn how this was possible: https://support.atlassian.com/contact/#/

You would think this would be possible in one rule...

trigger: sprint completed
branch: on issues in sprint
- condition: status is done
- condition: issue type is Story
- action: clone issue...saving the {{issue.key}} somewhere in the cloned issue's fields
branch: on created issues
- action: link issue using the saved key information

But branched issues process asynchronously and so there is no guarantee the first branch will complete before the second one starts AND finishes.

Kind regards,
Bill

Matteo Cristiani

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

Bill Sheboy

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.

Matteo Cristiani

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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

automation