Automation rule to link newly created Bug to existing Bugs linked to the same Task

[Kathryn Swearingen]

We use Tasks (not sub-task). We have one Task called "UAT". When a Reporter has a Bug to enter, they use Rules execution to manually trigger the creation of a new UAT Bug. That UAT Bug has logic built into it to assign one of three different labels (ex: Bug-Agency, Bug-CO, Bug-DX) depending on which group the Reporter belongs to. 

I need for all of the UAT Bugs with one of the labels (ex: Bug-Agency) opened from a particular UAT Task to link as "related to" to each other (Bugs), and each individual Bug also links as "blocks" against the UAT Task from which it was created. 

So:

When an Agency Bug is created (when issue created, with issue type of Task with label "Bug-Agency")

What comes next? Branch on JQL to find its linked UAT Task?
issue IN linkedIssues({{triggerIssue.key}}, "blocks") AND issueType = Task
Or some other way to find its linked UAT Task? 

Then find other Bugs linked to that UAT Task -- I'm very stuck here; can't get the correct rules/JQL

And then link all of those Bugs to each other as "related to"

So you end up with:
A UAT Task that has x # of Bugs with one of three distinct labels linking to it as "blocks" -- so the Bugs block the Task (meaning, we won't close the Task until all linked Bugs are closed) and all Bugs with the same label will link to each other as "related to". Doesn't matter at what point in time that the Bug issues are created (ex: days apart from each other with the possibility that other Bugs have been created in between, but those other Bugs have a different label). 

All of this is to ultimately write a rule that will add a comment in the UAT Task to announce that all linked blocking Bugs with a specific label are now closed. <-- that seems simple to say but it's been hard for me to execute. HELP! :-) 

[Bill Sheboy]

Hi @Kathryn Swearingen 

For an apparently complicated scenario like this, please consider diagraming this out (before and after), and post those images.  That may help the community to suggest how to create the rules you are asking about.  Thanks!

Kind regards,
Bill

[Kathryn Swearingen]

Hi Bill,

Thanks for the reply! Here's a quick flow I put together explaining our WoW and what I'd like to accomplish. 

[Bill Sheboy]

Well done on your explanation!

Just to confirm: do the Bug issues have labels for Agency, CO, or DX, or are those values in the summary?

If they are in the labels, you can find the "sibling" Bugs sharing the label and which block the same UAT Task with JQL.  And then use that JQL with the Lookup Issues action (rather than a branch).  With the Lookup Issues you can count how many match your criteria with {{lookupIssues.size|0}} to decide how to proceed.

The other way to do this is with is with same JQL and the related issues condition.  Although that approach will have less flexibility when you want to use any information from the specific Bug issues.

The other rule you note for transitioning the Story to done could similarly use the related issues condition or lookup issues action, with JQL, to decide when to make the transition.

Rules like this often require thinking with a divide and conquer approach: trigger on the change to the dependent issue's changes, find the parent, and then check the sibling issues of the triggering issue before proceeding.

[Kathryn Swearingen]

Hi Bill, 

Thanks and thanks for the reply! Yes, to confirm, like the explanation says I do make use of specific Labels (not values in the summary). 

I've approached this by triggering the automation when a Bug with the specific Label is transitioned to Done and then I had a branch that checks JQL to find the closed Bug's linked UAT ticket, using this JQL:
issue IN linkedIssues({{triggerIssue.key}}, "blocks") AND issueType = Task

but after this I get stuck on how to tell the automation that I now want to see if any other Bugs are open against that Task (not the trigger issue) with that Label. 

[Bill Sheboy]

I was suggesting that rather than use the branch, use Lookup Issues to find the UAT Task with your JQL to get the key; the key would be {{lookupIssues.first.key}}

Then you can use another lookup issues action to find the other Bugs for the UAT Task in the same way, but inverting the link direction:

issue IN linkedIssues({{lookupIssues.first.key}}, "is blocked by") AND issueType = Bug AND statusCategory != Done

[Kathryn Swearingen]

Apologies for the delayed response, I only get to work on Jira Automation in my "down time". While I've been in IT for over 20 yrs, query languages and Jira Automation are very new to me so I'm completely self taught, and only very recently. 

I understand what you're suggesting: don't need to do a branch like I had been, and I can use my JQL "issue IN linkedIssues({{triggerIssue.key}}) AND issueType = Task" to find the UAT Task that is linked to the Bug, but I'm stuck on what is meant by using that to "get the key", the key being {{lookupIssues.first.key}} -- can you explain this? 

Thank you!!

[Bill Sheboy]

No worries; automation requires a lot of self-teaching and experimentation.  I am learning stuff daily as I try rules and read community posts.

Would you please post images of your current rule and the audit log details showing the execution?  That may provide more context to make adjustments.  Thanks!

For the specific question you asked...

• My understanding was you used JQL to find the UAT Task issue in the rule
• I was suggesting to use the Lookup Issues action with the JQL, as that allows using the results found, and...
• Then other matching could happen, such as on the first UAT Task found: {{lookupIssues.first.key}}  As you are only expecting one UAT Task, this should still work.