Filter in lookupIssues for issues with linked issues with issyetype "Bug"

[Eelco Haeser]

Hey community,

I'm trying to make a automation work, but I cannot get it done.

Good to know, we don't have Scriptrunner (or any other "JQL enhancers"). JQL out-of-the-box doesn't seem to provide logic with linkedIssues. 

The use case is as follows:

• We have a project where Customer Support forwards customer calls on defects.
• These Cases are resolved in other projects, by linked issues (mostly Bugs, sometimes other types)
• For only Bugs we have SLA's.
• I'm trying to create a daily alert to Slack with a list of the Cases that have breached the SLA.
• So, I want to filter out the reported cases that only have linked Bugs.

The current setup is as follows:

First I create a {{lookupIssues}}

I've tried different things to filter down to only the issues with linked Bugs, but I cannot get it to work. If I create a branch and drill down with if-statements, it (logically) still prints all the lookupIssues. 

I've tried to do it with an #if-equals, but I can't seem to create the right smart value for the type of the linked issues:

{{#lookupIssues}}
{{#if(equals(issue.outwardIssue.fields.issue.Type, "10014"))}}
<{{url}} | {{key}} - {{summary}}> reported by {{reporter.displayname}}
{{/}}
{{/}}

Hopefully someone with a better understanding can help me with this. 

[Bill Sheboy · Accepted solution]

Hi @Eelco Haeser -- Welcome to the Atlassian Community!

From what you describe, I do not believe you need smart value, list filtering as you tried.

Instead, modify your JQL to search for issueType matching what you need and then list all of the issues found by Lookup Issues.  For example:

project = yourProjectName
 AND issueType = Bug
 AND priority = High
 AND status != Done
 AND status CHANGED TO 10131 BEFORE -192h
 ORDER BY cf[10047] ASC

Please adjust as needed to match your criteria.

Kind regards,
Bill

[Eelco Haeser]

Thanks for taking the time Bill!  However, or I don't fully understand your suggestion, or I wasn't clear enough 😇

The situation is as follows:

"Customer Case" (custom issuetype) in Project A links to ("Bug","Story", "Task") in projects B,C,D etc. in a 1-n relationship.

The SLA is measured against the Customer Cases, but only for those with (at least one) related Bug. 

In the daily Slack alert I want to list Customer Cases with SLA breaches (not the linked Bugs). 

I need the Lookupissues to create a single list in the message, rather than have a slack message for each single issue but I can't create a LookupIssues with a single JQL that filters issues with related bugs. There's no standard JQL query available for that without plugins. 😮‍💨

[Bill Sheboy]

Thanks for clarifying the scenario:

GIVEN a list of Customer Case issues
AND a Customer Case issue has links to other issues
WHEN one or more of the linked issues is a Bug
THEN return the Customer Case issue's data in a list of issues

Doing this one-by-one with JQL in a rule is possible using the built-in issue linking and other fields / operators.

Doing this to produce a single list of Customer Case issues is more difficult, for a couple of reasons:

• Once inside of a rule iterator, such as {{#lookupIssues}}...{{/}} only things from that scope and lower are visible.
  • Your rule would need to iterate over both the lookup issues AND their linked issues for the condition tests, making the "higher scope" data for the Customer Case not visible.  That is, the Customer Case key is not visible.
• For smart values like issuelinks, all their details appear to not be immediately available in rules in iterators.  Instead they are looked up with more calls to Jira.

A workaround is to walkover all of the lookup issues data, regardless of the link types, storing the results in a carefully constructed, created variable.  And then filter on that using the text match() function with a regular expression.

If you want more details on how to try this, please let me know.

[Eelco Haeser]

Superthanks for the clarification and the suggestion! I'll look into that (and will probably come back later for help 😅) 

[Eelco Haeser]

Update:

- I've found a workaround (couldn't wrap my head around your suggestion). Maybe it's not the most elegant solution, but it works 😇  I now use 2 rules for it.

- The first one updates issues after linking with a label if the linked issue is a Bug

- The simplified second rule now JQL's on this label and with lookupIssues I can cram it all in one message.

I'm still curious for your suggestion @Bill Sheboy not only for me, but for knowledge sharing (if you have time for it).

[Bill Sheboy]

I am glad to learn you have a workaround!

Regarding my other suggestions...my apologies in advance for the longer post / explanation :^)  First, an explanation of the challenges and then the workaround.

In my experience, two limitations with automation, list iterators are scoping and data availability.

Only data at the iterator scope, and lower, is visible. For example, assuming there is a trigger issue and a lookup issues action in a rule, we try this expression:

{{#lookupIssues}}
  {{#if(equals(issuetype.name, triggerIssue.issuetype.name))}}
    * {{key}} - {{summary}}
  {{/}}
{{/}}

The trigger issue data is not visible inside of the iterator, and so it cannot be used in conditions or other processing. 

That also applies as we move lower down, such as with nested iterators.  In your case, you wanted to filter on the linked issues and return the original one from the lookup.

{{#lookupIssues}}
  {{#issuelinks.inwardIssue}}
    {{#if(equals(issuetype.id, "10014"))}}
      * {{key}} - {{summary}}  <<< This is the linked issue!
    {{/}}
 {{/}}
{{/}}

However, once we are inside that nested iterator for issuelinks.inwardIssue, the higher-level data for the lookup result is not visible.  And so the key and summary for that could not be returned based on that conditional filter.

Additionally, when a rule loads the data for an issue, it does not load everything at once.  Yes, it has the summary, description, etc., but it does not load all of the data for the parent, subtasks, and linked issues.  If it did, you could imagine a scenario where a single issue reference pulled in all data for the Jira site due to circular, link references!

Jira appears to handle that by loading the additional data just-in-time, with more calls to the REST API.  For example, if a rule references the subtasks of an issue, it may need to call the REST API for each one accessed. 

That does not appear to be the case with iterators and linked issues.  Instead, some fields appear to be not loaded, evaluate to null values, and then things in the rule do not work as expected.

Now to the workaround...There are a couple of ways to iterate a list with automation rules and perform filtering:

1. {{#lookupIssues}} {{#if( some filter )}} return some data fields {{/}}{{/}}
2. {{lookupIssues.some field.match( some regular expression filter ).one data field}}

The first way can filter-on and return whatever you want, but is limited to the scoping and data availability challenges.

The second way is limited filtering on one thing and returning one field.

What if we could get the benefits of both?

One complicated way to do this is combine the data from the original list (i.e., lookup results) in to a single text string, then use that second method with match() to filter, and finally parse out the results needed.

For your case, the information in each looked-up issue (and its linked issues) could be merged into a delimited, text string and stored in a variable.  In my example, I only include the key of the top-level issue, without the URL, summary, and reporter.

I add a delimiter of ZZZ between the issue / linked issues, and ~~ between looked-up issues.  Let's call this variable varInward:

{{#lookupIssues}}{{key}}ZZZ{{#issuelinks.inwardIssue}}{{key}} a {{issuetype.name}}, {{/}}~~{{/}}

That would produce a text value like this, for issues in the project TEST, with several linked issues:

TEST-1ZZZTEST-11 a Bug, TEST-12 a Story, TEST-13 a Story, ~~TEST-2ZZZTEST-21 a Task, TEST-22 a Story, TEST-23 a Story, ~~

But you only wanted the issues with a linked issue which is a Bug, and so we split apart that text value and use match() to filter what is needed:

{{varInward.split("~~").match("(.*)ZZZ.* a Bug.*")}}

With a final result of only: TEST-1

There is a lot going on in this workaround with text and list functions, so I encourage reading more about them, if interested: 

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/
https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/

[Eelco Haeser]

Wow, really cool! And thanks so much for the comprehensive explanation, this is really educational. I'm going to try it out, because it feels like a good exercise to do so. 

[Mohammed Aamer Khan]

Hi @Eelco Haeser 

Try using below with an iterator

{{#if(equals(lookupIssues.outwardIssue.fields.issue.Type, "10014"))}}

[Eelco Haeser]

Thanks for the try, but unfortunately the slack message is empty :-(

So, apparently the if-statements returns only falses, which I know should not be the case.