Hi there. I have automation rules set up that add or remove a label based on the status of specific children of a story as follows: * When creating a sub-bug, add label "pending" * When when all sub-bugs are in "Ready for QA", "In QA", or "Closed", remove label "pending" * When reopening any of the sub bugs, add label "pending" What no longer works is the rule that removes the label when all sub-bugs are in specific statuses. This rule is supposed to look at only the sub-bugs linked to the story, and only if all of them are in specific statuses, it removes the label. The rule, start to finish, does this: * When any issue is transitioned to ready for qa, in qa, closed * If the issue is a sub-bug * Look at the parent * If the parent is a story * Look at the children of the story: - For all the sub-bug children - IF all are in ready for qa, in qa, closed * Then edit value in field "label" Here is a screenshot of the rule that no longer works: This used to work fine, and to validate the logic of my rule - if I change to "Some match specified JQL" it can easily check that one of the sub bugs is in the right statuses and change the label. What it can no longer check is that all the sub-bugs are in specific statuses. The audit log simply says "The following issues did not match the condition" for the parent story. In other words, even when all sub-bugs are in the right statuses, the rule says the story did not pass the JQL that checks that its sub bugs are in the right statuses. Thanks in advance!

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

"All match specified JQL" Related issues condition automation stopped working

Andrei Dediu_he9v52

Hi there.
I have automation rules set up that add or remove a label based on the status of specific children of a story as follows:

When creating a sub-bug, add label "pending"
When when all sub-bugs are in "Ready for QA", "In QA", or "Closed", remove label "pending"
When reopening any of the sub bugs, add label "pending"

What no longer works is the rule that removes the label when all sub-bugs are in specific statuses.
This rule is supposed to look at only the sub-bugs linked to the story, and only if all of them are in specific statuses, it removes the label.

The rule, start to finish, does this:

When any issue is transitioned to ready for qa, in qa, closed
If the issue is a sub-bug
Look at the parent
If the parent is a story
Look at the children of the story:
- For all the sub-bug children
- IF all are in ready for qa, in qa, closed
Then edit value in field "label"

Here is a screenshot of the rule that no longer works:

This used to work fine, and to validate the logic of my rule - if I change to "Some match specified JQL" it can easily check that one of the sub bugs is in the right statuses and change the label.

What it can no longer check is that all the sub-bugs are in specific statuses.
The audit log simply says "The following issues did not match the condition" for the parent story.

In other words, even when all sub-bugs are in the right statuses, the rule says the story did not pass the JQL that checks that its sub bugs are in the right statuses.

Thanks in advance!

Accepted answers

Dick

Hi Andrei,

Once you step into the branch "for parent" and checking for a story, the "issue at hand" is the story.

Any additional conditions (there is an AND statement next) for (a bunch of?) subtasks would yield you NO issues that are valid to do the edit on.

What you should do is replace the jql issue match statement with a lookupissues with 'parent link' = the story issue's key and still in an undesired "not ready" status.

In a subsequent if statement you can check the size of the lookupissues variable and compare it to zero. If that condition is true, all your sub-bugs are in the desired status and you can then proceed to remove the label "Pending" on the story.

I hope this can help you. If needed, I'm available to help further with the formulation of the exact automations.

All comments

Dick

Hi Andrei,

What you should do is replace the jql issue match statement with a lookupissues with 'parent link' = the story issue's key and still in an undesired "not ready" status.

I hope this can help you. If needed, I'm available to help further with the formulation of the exact automations.

Andrei Dediu_he9v52

Hi Dick, thanks for your answer.

Indeed, once I step into "for parent", all components are related to the parent.
However, I am using the "related issues condition" which checks the related issues of the parent.

Furthermore, in the related issues condition, I restrict the check only to issuetype = sub-bug.

So it's ok that I am performing actions against the parent, because I want to look at the parent's related issues, specifically the issuetype = sub-bug related issues, which fit the status JQL - and based on that I want to remove the label on the parent ticket with the edit issue fields component.

"Any additional conditions (there is an AND statement next) for (a bunch of?) subtasks would yield you NO issues that are valid to do the edit on."

I am under the impression you think my goal is to edit the issues, but what I actually want is to remove the label of the parent, and not perform any actions on the issues.

In other words - I am checking the status of the related sub-bugs of the parent when I transition any given sub-bug to specific statuses - and depending on all the statuses of the sub bugs relating to the parent, I remove the parent's label.

I may have not explained this well enough in my post.

Regardless, this has worked just fine before, and has only stopped working within the last 2 months.
I have revisited my rules recently, and I see that this one in specific no longer runs.

Looking forward to your reply!
Thanks.

Dick

Hi Andrei,

I've tested a similar query to yours. The linked issue statement highlighted in your picture is giving you ALL subbugs, since the first part doesn't restrict it to the parent issue you branched for.

The name "Linked" is deceitful here, it refers to the two statements inside the step. As you always end up with subbugs, the parent never gets the label removed.

Best modify the first part of this statement and include the parent using something like

parent = issuekey <-- this is the Parent originating from your branche.

Hope this helps you along,

Sincerely,

Dick

Andrei Dediu_he9v52

Hi Dick.
Sorry for the late reply here, it's been a busy period.

The image i shared indeed doesn't mention anything about the parent, but this is because it is part of a FOR loop that selects the parent.

So anything done after FOR should be done to the issue selected by the FOR component.

This is how it worked previously as well.

I am also unable to use parent = issuekey, unless issuekey here is a smart value that can bring in the issuekey of the trigger issue.

Here is a step by step of what the logic is.

For: Parent should get me to perform actions on the parent - and the JQL issues match is specifically for related issues on the parent of the sub-bug that was created

Andrei Dediu_he9v52

Hi @Dick

I made it work with your help! I found a smart value that tells me the parent of the trigger issue, so now I have "issuetype = Sub-bug AND parent = {{triggerIssue.parent.key}}" in the related issues component.

I think the issue here was the fact that i couldn't use "Sub tasks" in the related issues component, but rather "Matches JQL".
I couldn't use "sub tasks" because we use more sub task ticket types than just the sub bug.

In the related issues component, I am first selecting the issues with JQL, then comparing them to a second JQL so I can say "focus just on the sub-bugs".

However, it seems like this component doesn't ACTUALLY check for related issues. It's not implicit that the jql's will be run against whatever is related to the PARENT set with the FOR component.

Good learning points. Thanks again!

Dick

Hi Andrei,

I'm really glad you were helped here. It was a tricky one.

Thank you for marking the answer, it makes it easier for other people to find a solution if they are facing similar questions.

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