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; } } }

Does an automation consider a sub-task and a linked task the same?

John Ricard

I set up an automation to change the state of the parent when all the sub-tasks are changed to a specific state. (I attached the rule below for reference.)

Point 1 -Now we are using linked tasks and the automation seems to be executing more often.

Point 2 - I found that a situation where task 1 is linked to task 2 which in turn is linked to multiple other tasks, some of which link back to Task 2. This circular situation seems to use up all our automation execution quota very quickly.

Point 3 - I did not set the automation to change the parent task's state when the linked tasks change state, I built the rule to execute when the sub-tasks change state.

Does this mean that automation considers linked tasks and sub-tasks as the same?

If there are no sub-tasks, only linked tasks, why should this rule be running?

If the circular linking is the problem how do I prevent the circular linking of tasks?

Rule Photo.JPG

Accepted answers

Ste Wright

Hi @John Ricard

Linked Issues and Sub-tasks aren't treated the same.

Is this rule just executing? Or is it also actioning (i.e an automated action is taking place). You can tell this from the Audit Log...

Success = Actioning
No Action Performed = only Executing

For clarity, the rule executes even if it performs no action, or an Issue is filtered out by a condition.

It's likely your rule is executing a lot because the Trigger is so generic. It will trigger when any Issue is transitioned from any Status to any other Status. I'd look to limit this to the parameters in the rule - at minimum, that would be To - In Review.

I'd also consider...

Changing the first Condition to an Issue Fields Condition, and checking the Issue Type = Sub-task. The JQL condition here is adding no specific value, and as above, could be confirmed in the Trigger.
In the Branch's first Condition, I'd also switch this to an Issue Fields Condition. They're more refined than JQL conditions.

Ste

Mark Segall

Hi @John Ricard - I think you can do a few tweaks to this to refine/optimize how it is performing. I think the JQL calls are possibly causing the unwanted behavior. For example...

Combine the trigger and first condition. You should be able to set the issue transitioned trigger so that it only fires when issue is transitioned to In Review
Your first condition inside the branch could be changed to an issue fields condition where status does not equal ready for QA

This should dramatically reduce the overhead and make the rule work as desired.

All comments

Ste Wright

Hi @John Ricard

Linked Issues and Sub-tasks aren't treated the same.

Is this rule just executing? Or is it also actioning (i.e an automated action is taking place). You can tell this from the Audit Log...

Success = Actioning
No Action Performed = only Executing

For clarity, the rule executes even if it performs no action, or an Issue is filtered out by a condition.

I'd also consider...

Changing the first Condition to an Issue Fields Condition, and checking the Issue Type = Sub-task. The JQL condition here is adding no specific value, and as above, could be confirmed in the Trigger.
In the Branch's first Condition, I'd also switch this to an Issue Fields Condition. They're more refined than JQL conditions.

Ste

Mark Segall

Hi @John Ricard - I think you can do a few tweaks to this to refine/optimize how it is performing. I think the JQL calls are possibly causing the unwanted behavior. For example...

Combine the trigger and first condition. You should be able to set the issue transitioned trigger so that it only fires when issue is transitioned to In Review
Your first condition inside the branch could be changed to an issue fields condition where status does not equal ready for QA

This should dramatically reduce the overhead and make the rule work as desired.

John Ricard

Thank you for your response I have made the modifications suggested to my automation. See below.

Most of the last few hundred status show No Action Preformed and most of them point to the circular task that I indicated in Point 2 above and they are all timestamped either at the same second or up to 4 seconds apart.

Since the execution usage count is updated when a rule fires even if no action is taken could that circular task be using up a huge amount of the execution usage count allocation?

Rule Photo v2.JPG

John Ricard

@Mark Segall

Thank you for your response I have implemented your suggestions. Please see follow up question in response below.

Mark Segall

Yes the rule will fire for any issue that transitions to In Review and then quickly exits if it isn't a sub-task. Question... What is the scope of this rule (Is it a single project, multiple project, or global?

If it's global, you may want to evaluate whether that's truly needed. Maybe it can be set for a single project or a more refine multiple project scope.

John Ricard

Hi Mark,

Thank you for your persistence with this issue.

There are only three of the large projects using this automation. They all need it.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud