Smart Values - filter and print labels field

[Jacob Stephenson]

Hey there!

I currently have a custom field "Field A" of type labels. I have an automation which generates a subtask, then populates the description with the labels. This currently runs through

{{triggerIssue.Field A.join("\n")}}

 I find the same result using

{{#triggerIssue.Field A}} {{.}} {{/}}

I've written the labels in the format "Table:column", referring to relational database tables and columns , e.g. "Events:score" or "Colour:value".

I want to display only those labels which start with "Events:" in my new subticket, but I haven't been able to get the if logic working at all. For instance, even the following prints nothing into the description

{{#triggerIssue.Field A}}
{{if(.)}} Hello!
{{else}}
Goodbye!
{{/}} {{/}}

What's the solution?

[Bill Sheboy · Accepted solution]

Hi @Jacob Stephenson -- Welcome to the Atlassian Community!

There are at least two ways to do this with automation rules...

Use the match() function with a regular expression to return the list of matching labels:

{{issue.labels.match("((Events|Colour):.++)")}}

Use the iterator (as you are trying) with text functions, and a variable.  Some rule functions can work with an implied parameter within an iterator.  In this case, we use startsWith() with the implied {{.}} as the source, and then later extract the matches back into a list.

• action: create variable
  • name: varFilteredLabels
  • smart value:

{{#issue.labels}}{{#if(or(startsWith("Events:"),startsWith("Colour:")))}}{{.}}, {{/}}{{/}}

• Use the variable to create the list of values needed.  Note that we always added a comma after values above, and so that must be removed before splitting the list.

{{varFilteredLabels.substringBeforeLast(",").split(", ")}}

Kind regards,
Bill

[Jacob Stephenson]

Thanks Bill!!

I've attempted the top solution so far, which is more elegant and for which I thank you. Will check the other for my education.

Yours gratefully,

Jacob

[Bill Sheboy]

Awesome; I am glad to learn that helped!

Each approach has its benefits for searches / parsing, so they are good to keep in the toolkit:

• The first one searches on the entire inline, iteration value, and then requires more parsing for structured result handling.  And it supports dynamic searches for stuff outside of the iteration scope.  e.g., One field contains the search criteria to search within another field.
• The second one filters on any field within the iteration scope, and then allows processing of other fields.  e.g., Filtering the result of a Lookup Issues action to make a bulleted list of issue data.