How to select a date from an issue description (generated from an email)?

[Matt Miller]

This can be via regex or otherwise. We're trying to autopopulate the due date field on Jira issues that are generated from inbound email. I attempted to do this through automation by creating a rule that updates the issue field with the value of 

{{issue.description.match("(?<=Due Date: )\\d{2}/\\d{2}/\\d{4}")}}

I'm not sure if this is the correct syntax for Jira or not, but my attempt was to have it search the issue description and match the regex for "Due Date: mm/dd/yyyy". Thus far it hasn't worked. Has anyone done this and have a working solution?

[Bill Sheboy · Accepted solution]

Hi @Matt Miller 

Short answer: I recommend not trying any complicated regular expressions with automation rules as there is no documentation on what is (or is not) actually supported.  Perhaps try the simplest thing that could possibly work, adding edge cases only when needed, and testing fully.

For example you could try either text functions, chained matches, or a mix:

{{issue.description.substringAfter("Due Date: ").left(10).toDate("MM/dd/yyyy")}}

{{issue.description.match("(Due Date: \\d{2}/\\d{2}/\\d{4})").substringAfter("Due Date: ").toDate("MM/dd/yyyy")}}

...

Kind regards,
Bill

[Matt Miller]

Thank you for the reply Bill! Would you try these in the same contexts? Here's how I had that regex set up previously, with "Due Date" as the selected field obviously.: 

[Bill Sheboy]

In my experience, the only way to know if something works with automation's implementation of regular expressions is experimentation and testing.  So try it, and if it works, great!

There are several community posts observing expressions which work in other regex parsers and do not work in rules, such as some of the on/off flags.  Some other possible challenges with rule use of regex are:

• As per the documentation, only one match group is provided
  • Workaround: match on an entire larger expression, then use text functions or additional matches to parse out the pieces
• Racetrack errors, where the match() or replaceAll() may not process fast enough for the usage.  This definitely happens in the Send Web Request action, the Edit Issue using dynamic JSON, and sometimes with Asset value parsing.
  • Workaround: when possible, use a created variable to fully evaluate the expression first, and then use the variable where the match() would have been used
• Escaping characters in the search expression may not process as expected
  • Workaround: using three created variables, first create the regular expression, then use two other variables to perform escape addition / replacement, and finally use the result as the match() parameter
• Cannot use issue fields / smart values in regular expressions directly
  • Workaround: create the regular expression with the other fields in a created variable, and then use that variable as the parameter in the match()

[Matt Miller]

Hey Bill, sorry for the late reply but my users got to testing, and it looks like your first text function option worked like a charm, thought you might like to know! Wouldn't have even known/thought to try something like this. Appreciate your help!