Advanced compare of variable parsed from Description always fails

Question

We have Defender alerts emailed directly into a JSM project. The Description ends up coming through like this:

I am parsing the various bits of information (ID, Severity, Categories, etc.) out of the Description and storing them in variables for use later by using regex like {{issue.description.match("Severity[]*+([^]+)")}}. This works, and the audit log reflects the intended data is captured. I am assuming that expression is capturing more than just the text characters though.

When I try to branch and use advanced compare to take different actions depending on if the Severity level is Medium, High, or Critical, I cannot get it to work.

I assume this is either due to the way Jira is storing the text for the variable or because there are a bunch of other hidden characters that are getting captured when the regex grabs the line (email comes to Outlook with html formatting).

I have tried adding .trim() to the capture as well as overwriting the Description with {{issue.description.text}} before the variable is created. I have tried numerous iterations of the first value in the advanced compare...

{{varSeverity.startsWith("High")}} equals true

{{varSeverity}} contains regular expression (High)

{{varSeverity}} starts with High

{{varSeverity}} equals High

{{varSeverity.substringBefore(" ")}} equals/contains/starts with/etc.

...and a bunch of varSeverity remove/replaceAll attempts to remove white spaces, non alpha characters using [^a-zA-Z] and about every other possible combination I could think of to no avail.

If I simply add a second Create Variable step to the top branch and use {{varSeverity.substringBefore(" ")}} for its value, the same advanced compare - variable contains regex (High) - works. Likewise if I post {{varSeverity}} as a comment on the ticket, then capture it with a second variable using {{issue.comments.last.body}}, the same compare will work against that variable.

I realize I have a working solution with the second variable option, but it just feels like I am missing something that would allow me to do it without that second variable. I am not particularly skilled with regex - generally I have to find examples online to modify for my own purposes, so I am somewhat of a novice.

I appreciate any insight!

Bill Sheboy · Answer

Hi @Robert Hook

There is no documentation on what does (and does not) work for regular expressions in automation rules.  What the docs state (with italics added by me) for the match function is:

Performs a regular expression search and returns the first (and only one) matching regular expression group.

The underlying implementation is based on Java's Pattern class and uses Matcher.find() to find matches.

However, there are plenty of community question examples where people tried regex that worked elsewhere, or aligned with the Java spec, and it did not work the same in match(), replaceAll(), etc.  Additionally, there appear to be consistency problems when the source field (e.g., Description) contains newlines, and racetrack timing problems for dynamic expressions.

Some things to try are:

* Replace all newlines in the source text with some known value before the match attempt.  When the newlines are needed again after the match, replace them back.  For example:* {{issue.description.replace("
", "~~").match(myRegEx).replace("~~", "
")}}

* When in doubt, trim before attempting comparisons / condition checks on results of things like match() results
* Remember match() produces a list of values.  When things do not work as expected, perhaps check the size to confirm you are getting the number of returns you expected.
* Use the simplest possible regex which could find your value(s), experiment to validate the results, and then incrementally add to the regex for edge-cases, etc.  As a variation of this method, chain together multiple match functions to get at the results, such as with {{issue.description.match(myFirstRegex).match(mySecondRegex)}}
* When the regular expression contains escaped characters or is dynamically built from other data, use a created variable to build the regex for use.  This will force it to fully evaluate as plain text before use in the match() function.  For example:* action: create variable* name: varRegex
* value: (my regular expression)

* action: needing the match...* {{issue.description.match(varRegex)}}

Kind regards,
Bill

Mikael Sandberg · Answer

Ever since Atlassian made an internal change to automations I have noticed that you have to use two variables when using regex or any of the format text strings, so that is the way I have dealt with it for the past 6 months or so.

Robert Hook · Answer

nm