Automation rule to validate labels against regex triggers when it shouldn't

[Elodie Ferreira]

I've been trying to set a rule to validate the labels of a Bug to ensure they belong to a fixed set of allowed values. The rule is simple, if any value was entered that doesn't match the regex, the reporter of the issue and the person who modified it will both receive an email and a comment will be added to the issue.

The allowed values will include a list of specific words plus:

• MERGE_X.X
• X.X.X-rcX
• GLOBALMTOM-X

where X are digits.

I've been reducing the regex trying to make the rule work, and I'm currently testing with only this (the specific words only):

(ALERTS|API|BILLING_ACCOUNTS|BULK_FILES|CIR_FILES|COMMUNICATIONS|CUSTOMERS|DASHBOARDS|ENDPOINTS|EXTRACTORS|ICCID_PROVISIONS|IMPERSONATE|INFRASTRUCTURE|ORDERS|REPORTS|REQUESTS|RESOURCES|SERVICE_ACCOUNTS|SIM_REPLACEMENT|SMS_CONSOLE|USER_MANAGEMENT|USER_NOTIFICATIONS|DOCUMENTATION|REGRESSION|Smart2M_MEO)?

Problem is, not matter what I enter on the field Labels of a Bug, allowed or not allowed values, the rule is always triggered.

This is how the rule is configured:

[Bill Sheboy · Accepted solution]

Hi @Elodie Ferreira -- Welcome to the Atlassian Community!

Adding to the suggestion from @Dick explaining how the list needs to be evaluated...

Given the challenges / uncertainties of automation rule handling of regex with match(), I recommend:

• use the simplest thing that could possibly work
• take complete control of the matching / list evaluation rather than using the regex handling provided by rule conditions
• only add edges when needed
• test thoroughly

For example, you want to identify when unknown labels are used.  To do that, try to specifically match that way and then count the results.  For example, to find the labels that do not contain "apple" or "red", this would work:

{{issue.labels.toLowerCase().match("^((?!.*(apple|red).*).*)")}}

That expression would also remove any embedded values (e.g., my-Apple).  And, I forced the labels to lower case before the match() for improved readability.  Please adjust to match your scenario.

Now to check the count, add size to the end and compare the count is greater than zero.

Kind regards,
Bill

[Elodie Ferreira]

Thank you! With @Dick 's answer and yours, I finally made it work.

This is my final configuration and it works exactly how I wanted to.

[Dick]

Thank you for letting us know, @Elodie Ferreira. That surely brightens up the start of the weekend!

Kind regards,

Dick

[Bill Sheboy]

Um...I am unclear how that condition works with the option "does not match regular expression". 

The first value {{#issue.labels}}{{/}} would return null because no values are returned inside the iterator.

What I was suggesting was this to detect when there are stray labels:

• smart values condition:
  • first value: {{issue.labels.toLowerCase().match("^((?!.*(apple|red).*).*)").size}}
  • condition: greater than
  • second value: 0

This explicitly tests the count of non-matching labels found.

[Elodie Ferreira]

I understand your point, fact is, it's working exactly like I needed to.

But I'll set a second rule with your suggestion to see how it works and then let you know. Just out of curiosity.

[Dick]

Hi @Elodie Ferreira 

It's always wise to be one step smarter than your users, so I fully endorse going the extra check (could be a single condition in your automation) as suggested by @Bill Sheboy .

Kind regards,

Dick

[Dick · Accepted solution]

Hi @Elodie Ferreira Welcome to the Atlassian Community

The smart value in your second condition is a list of possible label entries and should not be treated as a single value. 

You should iterate through the list using {{#issue.labels}}{{/}} as per documentation on lists:
Atlassian on list variables

Kind regards,

Dick

[Elodie Ferreira]

Thank you! I finally made it work.