Filtering smart value lists

[Bill Sheboy]

Hi @Josh Marsh 

I recall experimenting with {{index}} within iterators a few years ago, discovering it appears to be a just-in-time attribute of the list iterator and does not exist in a way which permits use in functions, filters, etc.

A possible workaround is to expand the list into another variable with each index, and then use inline filtering with match().  Perhaps like this:

• action: create a new variable, which creates a delimited list of index and value pairs
  • name: varExpandedList
  • smart value: {{issue.Impacted Users.split(",")}}{{index}},{{.}};{{/}}
• action: some other action to extract the values
  • for example, this would return the first 11 of them, as {{index}} is zero-based
    • {{varExpandedList.split(";").match("^(([0-9]|10),.+)$").substringAfter(",")}}

Please research regular expressions to find one that works for your range of index values.

What is the source of your list of "Impacted Users"?  Knowing that may help to suggest other options.

Kind regards,
Bill

[Josh Marsh]

Hi @Bill Sheboy ,

Thanks so much. Using match() was a great idea.

FYI in the end (with a little help from ChatGPT), these were my successful regular expressions:

• First 100 values
  {{varExpandedList.match("^((.*?;){99}.*?)(;|$)").split(";")}}
  
  
• Second 100 values
  {{varExpandedList.match("^(?:.*?;){100}((.*?;){99}.*?)(;|$)").split(";")}}

I didn't need to use index at all in the end, since the match() function seems to respect the original order of the list.

And since you asked, the list of Impacted Users comes from a query run in Excel, which is then copy and pasted to the custom field in Jira.

Thanks again,
Josh

[Marvin Brand]

Hey community I need your help here, 

I want to make use of the {{#lookupIssues}} function and use if-condition for further filtering the fetched issues.

Use case:

I want to two lookupIssues lists in a comment or description field.

The first Issue list:

Every fetched issue should be checked whether its "customfield_10110" has the same value as the "customfield_10110" from the current issue, where the automation is triggered from. If it returns TRUE, the issue key should be listed in a bullet point list.

The second issue list should contain all the other issues, where the condition is not met.

FYI: In customfield_10110 we store supplier names. So in other words I want to get a list of other issues, which have the same supplier in the custom field like in the trigger (current) issue.

It seems like I cannot compare a value from the current (trigger) issue with a value of the looked-up issues. The manual triggered automation won't create a comment or post a new description field text.

I tried the following things:

Test 1 – referencing the 2nd compare value (from trigger issue) with a smart value in  {{brackets}}

{{#lookupIssues}}
{{#if(equals(customfield_10110,{{issue.customfield_10110}}))}}
* {{key}}
{{/}}

Test 2 – referencing the 2nd compare value (from trigger issue)  with a smart value in "{{brackets and quotes}}" to make it a string

{{#lookupIssues}}
{{#if(equals(customfield_10110,"{{issue.customfield_10110}}"))}}
* {{key}}
{{/}}

Test 3 – storing the supplier name (customfield_10110) as a variable "currentsupplier" and trying to reuse the variable in the if-condition

{{#lookupIssues}}
{{#if(equals(customfield_10110,{{currentsupplier}}))}}
* {{key}}
{{/}} 

Any ideas folks? 

@Bill Sheboy I see a lot of engagement from you in the Atlassian community and it looks like you always have good ideas :)

Please guys, have a solution for me 

Thanks in advance!

Marvin

[Bill Sheboy]

Hi @Marvin Brand 

As this is an older thread, I recommend creating a new question and including a link to this thread for context.  That will ensure better visibility and focus on your scenario.  Otherwise, only people following the older posts will see it.

Until we see your new question...

Long-format iterators have a known limitation where they cannot "see" data from outside their scope.  And so once inside those {{#lookupIssues}} ... {{/}} iterators, they cannot access other issues, variables, etc.

There are two possible workarounds for your scenario:

1. Add your criteria to the JQL for the lookup action, and store the resulting keys in a variable (or lookup table) for later use.  Then repeat those steps for each lookup needed.
2. To use a single lookup work item action, use the dynamic searching methods described throughout this thread, or in this article I wrote on the method.

Kind regards,
Bill