Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,359,795
Community Members
 
Community Events
168
Community Groups

Change the state of Story to the lowest status of subtask

Hey community. 

I am wondering - is it possible to assign the 'lowest' (or the earliest) status of a subtask to the parent issue? 

Our workfflow is 'todo -> in progress -> in review -> in qa -> done'. Lets say we have:

Story 

- subtast1 - status 'in progress'

- subtask2 - status 'in review'

- subtask3 - staus 'in qa' 

I want the parent story to have status 'in progress' - same as subtask1. If subtask1 status is updated to 'in qa' - I want Story status to be updated to 'in review' (equals subtask2 status now). 

3 answers

2 votes
Mykenna Cepek Community Leader Oct 06, 2021

Yes, I've done this. It sounds simple, but it's actually rather tricky with Jira Automation. I'll try to summarize the approach that is working for us.

-  -  -

Rule A triggers on Create, Update, Transition and Move. It uses a Conditional right away to focus only on Story-level issues (so this rule ignores Epics and Subtasks). It then goes through a series of conditionals:

  • If Story.Status != LowestStatus AND some Subtasks have Status=LowestStatus THEN transition Story to LowestStatus
  • Same for NextLowestStatus
  • Repeat through HighestStatus

So "todo" would be your LowestStatus and "done" would be your HighestStatus, with 2 in between. See the "important notes" below for exiting the rule after a conditional has fired successfully.

Note that Rule A will "force" the Status of a Story to be correct, based on the Subtasks. This prevents users from updating a Story to be inconsistent. It can seem odd on a Jira board, though to move a Story and then have Automation move it back. Boards that use swimlanes by Story work best here, helping users to focus on moving their Subtasks.

-  -  -

Rule B uses the same trigger as Rule A, but the initial Conditional focuses on Subtasks (so this rule ignores Stories and Epics). It also uses a series of conditionals:

  • If Parent.Status != LowestStatus AND some sibling Subtasks have Status=LowestStatus THEN transition parent Story to LowestStatus
  • Same for NextLowestStatus
  • Repeat through HighestStatus

Again, see the "important notes" below for exiting the rule after a conditional has fired successfully.

-  -  -

A few additional important notes:

  • I use a variable called ContinueFlag which is initially set to 1 (meaning the rule should continue executing). If a conditional matches, I set that variable to 0. Then after that conditional and the next one, I test the ContinueFlag in a Condition. The rule only continues if it is 1. That makes the rule terminate after the first matching conditional.
  • I would recommend getting Rule B to work first, as it is easiest to test (perhaps in a separate project).
  • Once you have both rules working, you will need to "bootstrap" each project (or if you're really brave, lots of projects). To do that, copy Rule A and change the Trigger to a Scheduled Trigger, use a Cron Expression of "0 0 0 1 1 ? 2000" (to keep it from executing), and check "Run a JQL search and execute actions for each issue in the query". For that JQL use "IssueType not in (Epic, Sub-task) and StatusCategory != Done". This focuses on only Stories which are not Done. You can use the "Run rule" button to bypass any schedule.
  • This works well for Scrum teams/boards/project, but not so well for Kanban. This is because of how Jira handles the Backlog. Let me know if you want more details about the complexity that Kanban adds.
  • Consider creating a set of manual "unit tests" that you can walk through and confirm proper operation. You'll likely make adjustments and enhancements to these (complex!) rules over time. And it always helps to be able to confirm that they are still working as expected. I documented those test steps and expected results in a Confluence page for my fellow Jira Admins.
  • If your rules evolve to be more complex, you might find a need to use the "Re-fetch issue data" Action, or the "Sub-tasks present" Conditional, to ensure proper behavior.
2 votes

Hi @anastasiia_levdyk 

You need to create a branch rule and use "Type of related issues" as parent along with few conditions I believe you can achieve this.

Something like this.

ksnip_20211006-160104.png

I have explained this here if you want to get more details.

I hope it helps and gives you some direction.

Ravi

0 votes

Hi @anastasiia_levdyk 

I believe the solutions suggested by both @Mykenna Cepek and @Ravi Sagar _Sparxsys_ will help you, and...please remember to think of edge-cases when testing your rule. 

For example, what if someone accidentally moves a subtask and then moves it back quickly to its original status.  Both moves would be seen by automation as events...however...the automation engine may "decide" not to trigger the rule again as it could detect this as a looping problem.  Think of this and other scenarios when you test the rule.

Thanks, and kind regards,
Bill

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Atlassian Automation

Jira Automation: Sum Up Story Points Roundup (Initiatives -> Epics -> Story/Tasks -> Subtasks)

Hi Everyone, In this roundup we combine all the jira automation rules to sum up story points across different issue types. We start from the lowest level, summing up story points from sub-tasks t...

3,098 views 10 9
Read article

Atlassian Community Events