Change the state of Story to the lowest status of subtask

Question

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

Jeff Hooper · Answer

Hi @Mykenna Cepek

Will you please share your automation that creates and sets the ContinueFlag, then uses it to determine when to make the rule exit? I'm new to automation, and I don't know how to add a condition to check a custom variable. I also don't know how to terminate a rule. I'd appreciate your assistance.

Bill Sheboy · Answer

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

Mykenna Cepek · Answer

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.