Getting the linked issues count using jira automation

[Gayathri B]

Hi, 

I am trying to write an automation where 

1. The trigger is "Issue linked" and it is automatic trigger not manual

2. The automation should search the linked issues and scan through the linked issues severity field. 

3. Based on the Severity : High / medium - it should update in High = X and Medium = Y field.

4. Most importantly it should increment the count, everytime an issue gets linked to the parent ticket. 

I have tried a way using branching rules and lookup issues condition - but it takes a long time to return. What can we do here? 

[Trudy Claspill]

Hello @Gayathri B 

You said:

everytime an issue gets linked to the parent ticket. 

With generic issue linking there is not a parent/child relationship recognized by Jira. 

What link types are you using? And how do you know which issue is considered the parent in those link relationships?

[Gayathri B]

In our use case, we will be using "is blocked by" link for linking all the defects that get raised during the testing of the parent ticket. That being said, only the defects will be linked under this link by our teams. So it is only up to us to get the count of all the linked issues separated by the priority and then taking this count for our further reporting mechanisms. 

The issue trigger is "issue link deleted", this is the exact same logic for "issue linked" as well. So I just want to get the logic below that to be checked. 

The branching mentioned below extends to two more severity types. So on the whole there are 3 branches. Everytime the automation gets triggered, it goes through all branches and takes upto 6-7 secs to run which is slowing the process. 

Logic for getting the "urgent issues count" is {{lookupIssues.size}}

I want to optimise this by options to reduce branching logic or alternate methods

Thanks!

[Trudy Claspill]

You said that the rule is taking a long time to return. Does it consistently take longer than the rule that is triggered by Issue Linked that otherwise references the same destination issue?

How many issues are you retrieving in the Lookup Issues actions?

[Gayathri B]

Hey Trudy,

My comparison was between a manual and an automated trigger. 
A manual trigger will run only when it is called out, and since it is manual the team will not be calling it again and again and would only trigger it when they are done, or midway sort of. 

But when I try to automate this, where in everytime when a new defect is linked, the rule has to automatically run, logistically taking 6-7 secs for every new defect getting linked does not look like a good rule built. 

So I want to refine it. It could be shrinking 3 branches to 1, or using some other conditions that ensures the rule is automated and still running in an optimised manner

during my testing, I used 4 -5 issues linked 

[Bill Sheboy]

Hi @Gayathri B 

Perhaps posting more context will help diagnose this symptom.  Please post the following:

• An image of your complete rule, in one single image file for continuity
• An image of the audit log showing the history of executions and their duration times
• An image of the most recent execution (which was perceived to be slower) showing the audit log details with all the areas / dropdowns expanded.  Again, please post that in a single image file for continuity.

Thank you!

Kind regards,
Bill

[Gayathri B]

[Gayathri B]

Hey @Bill Sheboy more screenshots as per requested

[Trudy Claspill]

Can you share the rule audit log output for when the rule was manually triggered?

[Bill Sheboy]

Thanks for that information, and assuming you are using Jira Cloud...

Your rule is branching, looking up issues, and editing an issue three times, so that amount of run time is not unexpected.  The rule is making at least 6 calls to the database after the rule starts.

To reduce the duration the rule needs to perform fewer steps, or perform them more efficiently.  You could improve the rule as follows:

• use one single Branch, as it is always to the same issue
• use one single Lookup Issues action, removing the JQL filtering on the Severity
  • issue IN linkedIssues({{issue.key}}, "is blocked by")
• use one single Edit Issue action, updating all of the counts at one time, using smart value list filtering and a math expression to get the counts

For example, the count for Urgent would be:

{{#=}}0{{#lookupIssues}}{{#if(equals("Severity[Dropdown]".value, "1 - Very High"))}} + 1 {{/}}{{/}}{{/}}

How that works is:

• iterate over the looked up issues
• filtering for ones matching the severity needed
• and when found, add + 1
• wrapping all of that in a math expression, with a 0 at the front for a default

To get the other counts, change the value tested in the equals() function.

Please note well: smart values are name, spacing, and case-sensitive.  And, they do not necessarily match the field name displayed on the screen or in JQL.  To confirm you have the correct smart value (or custom field ID) for the "Severity[Dropdown]" field, please use this how-to article: 

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[Harrison Ponce]

Hi @Gayathri B ! This sounds like a very interesting use-case :-)

Would you mind sharing a screenshot of what you have set up so far in your automation? I'm trying to understand where the count of linked issues is being stored in your case.

[Gayathri B]

yes you got that in my reply above! @Harri