Changes in Initiative status depending on the activity of Tasks/Sub-Tasks

[Kostiantyn Syvachenko]

Hello!

In our project, we use 4 types of issues: Initiative, Epic, Task, and Sub-Task.

Initiative - Summary = project name, client details, etc.
Epic - project stages
Tasks and sub-tasks are specific project tasks; they are what engineers work on.

Tasks and Sub-Tasks have separate workflows and status automation. Initiative and Epic statuses are independent of them and are not yet automated.

The goal is to change the Initiative status based on the last Task/Subtask status change or the last worklog.  That is, if ALL existing tasks and sub-tasks in the Initiative satisfy the following JQL request, the initiative's status must be changed without affecting the epic.

JQL request statusCategory != Done AND (NOT status CHANGED AFTER -14d OR worklogDate <= -14d).

There are some ideas, but I don't have any))

[Bill Sheboy]

Hi @Kostiantyn Syvachenko -- Welcome to the Atlassian Community!

As your work items all appear to be in one space / project, and you are asking this question about an automation rule, assuming the trigger is Work Item Transitioned...

Without seeing the specifics of your complete rule, the audit log details, and the status workflow for the relevant types, I suspect you could do this using and of these methods:

• related work items condition with JQL
• one, or more lookup work items actions followed by smart values conditions
• a branch on JQL, followed by a single lookup work item action, then followed by a smart value condition

As a related question, you describe "the initiative's status must be changed without affecting the epic."

Why do that?  When the child Tasks of the Epic transition status, and you expect the Initiative to change also, it would likely make sense for the Epic's status to change in the same manner.

Kind regards,
Bill

[Kostiantyn Syvachenko]

The trigger should be a scheduler that searches for tasks and subtasks based on the query:

project = B4AT AND statusCategory != Done AND type IN (Task, Sub-task) AND (NOT status changed after -7d OR worklogDate <= -7d) 

Changing the status of just the Initiative isn't particularly important; that's what my colleagues want.))

The problem is that I can only check the status of all tasks one level down, not two (Parent-Child-Grandchild). How can I ensure that all tasks at the child-grandchild level in that hierarchy satisfy the request?

[Marc -Devoteam-]

Hi @Kostiantyn Syvachenko 

Based on JQL , you would need a 3rd party app that extends JQL options, as this can't be done with ootb JQL.

But this said you would 1st need to incorporate the Epic level as well as, this is till needed.

You can't skip a level.

[Bill Sheboy]

Yes, and...to what @Marc -Devoteam- describes:

With a single JQL expression, a marketplace app / addon which extends the JQL features would be required.

With multiple JQL expressions, and multiple Lookup Work Items actions as I described earlier, this is possible with built-in features:

• assuming the rule is triggered on a Task
• use the first lookup and JQL to find all relevant siblings of the Task for their parent
• use the results of that lookup to build a dynamic JQL expression which includes all of the Tasks and their Sub-tasks; e.g., key IN (ABC-123, ABC-345, ...)
• use that dynamic JQL in another Lookup Work Items action to gather / test the work items, checking the results
• this will only work if the expected total number of work items is 100 or fewer

Whichever approach you use, I recommend carefully testing any JQL with examples outside of a rule, confirming it works before making any automated updates.  Better still, test the JQL and rule in a separate test project to ensure it does not impact your production work items.

And, regarding your note:

Changing the status of just the Initiative isn't particularly important; that's what my colleagues want.))

I strongly recommend having a discussion to understand why your colleagues want that behavior.  To me, it does not seem to make sense from either a work tracking or a rollup perspective for the child and grandchild work items to skip a level in updating the status.