You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Currently below is a ticket structure. M2-34 has two linked tickets (M2-35) & M2-36)
M2-34 (Story) -> M2-35 (Task 1) - with label 'Dev'
-> M2-36 (Task 2) - with label 'QA'
To Do -> Read for Work -> In Progress -> in Review -> Done
Objective: When ticket M2-35 is in 'Done' then transition M2-36 into 'Ready for work'
Would this be possible in Jira automation?
Would need some more detailed information about your setting:
Thanks in advance.
M2-35 & M2-36 are Tasks (on issue level) linked to Story (M2-34)
Linking: 'relates to'
Below is how it will look like. I have a Story that is liked Tasks (notSubTasks). Each of these functional teams have their own board.All Tasks are in 'To Do' status. So when the Dev Task is 'Done' then move QA Task to 'Ready For Work', for example.
How is the dependency between those issues done? As these issues don´t have a parent/child relation how are the linked? That would be an important information to know how to call one issue from another one and finding an ideal solution.
Is there any just cause to work with tasks instead of subtasks? The described setting seems to me as the good practice in Jira to formulate subtasks for work that implements the story. Furthermore this eases a lot of things in regard of transperency (as well as for automation).
Basically, the Tasks will then appear on each respective team's board.
The tickets are linked based on 'related to' to a story ticket. I managed to get it work however currently looking for a way to have all the development tickets (Tasks with 'FE:Web' or 'BE') done state before transitioning Task ticket label 'QA' to Testing.
Unfortunately I can´t think of a fitting solution here. I´m not sure if jira automation is sufficient to solve this tricky and kinda complex setting of issue-linking as this would need to nest several branches. At least my current knowledge is not sufficient at this point.
Some more question to the issues/relation:
First you will need to create a rule that will be triggered by the transition and does a check if the label is "Dev". Add a new branch related to the parent.
Depending on if you use server or cloud you want to start a different action
After that you can create a second rule that is triggered upon the event or change from the first rule. Again use the branch rule but this time target the subtasks and check if it has the label "QA".
Don't forget to enable "Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule." in the rule details.
I am currently using Jira Cloud. All Tasks are same level as Stories (we are not using subtasks).
Currently got this work!.
Now the next step is how do I check to ensure that all development related tickets (labeled - FE:Web or BE) are done before moving the QA labeled tickets.
We can do this via in Automation for Jira. A sample below i had written for our projects you just have to replace the Status in JQL and in action. Also another note is in Branch "For Linked Issue" Substitute the links of your issue.
Hope this helps !!
We have a situation where we are trying to transition linked issues, but the transition has a sil script validation that requires field X be filled in. Even though the linked issue does have this field filled in, the automation rule is failing during the transition saying that field X must be filled in. Field X in the linked issue isn't being modified in the automation rule, so how can I get past this failing validation? I'm guessing re-fetch won't do anything since it will pull in data from issue that triggered the rule, which isn't the linked issue.