Jira Automation: how to read the previous state of an issue?

Question

Dear community,

I would like to now the previous state of an issue within a Jira Automation.

I can get the change history of an issue via web request:

I then read the response into a variable by {{webhookResponse.body.changelog.histories.items}}.

There are all the changes, which have been done to an issue.

Question: how do I parse it down to the previous state of the issue?

I tried to follow this approach by @Erin Quick-Laughlin, but I am very much struggling with the {{smart values}}.

https://community.atlassian.com/t5/Automation-questions/Re-Re-How-to-parse-through-an-json-array-where-field-na/qaq-p/2297738/comment-id/6353#M6353

I have tried this, but get an empty audit log back:

Any help is very much appreciated.

Chris

Bill Sheboy · Answer

Thanks for your extra analysis, Christian!

Answering your last question, first...no, there is no way to read all possible responses as JSON.  I recall there is an open suggestion to add a text function for rules to correctly interpret as JSON, allowing dereferencing by attributes at all levels / structures.

Next regarding use of more advanced, complicated regular expressions...the documentation states this, with emphasis added by me:

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

I have not found stated what is / is not supported in regular expressions for rules.  Several community posts indicate expressions that work with other regular expression parsing tools do not work the same in automation rules.  This can be caused by the parsing order, particularly when escaping characters is used.  (One workaround for that is to store the expression in a created variable first, and then use it in the match() function.)

I recommend using the simplest regular expression that can possibly work, testing, and incrementally adding to handle edge cases.  And if you have something that works, save that expression / rule, before modifying to enhance it.

Regarding the performance, I suspect at least 1 second of that time is for the Send Web Request call.  And I have observed both complicated regular expressions and large text strings adding to rule run time.  I cannot tell from your question if you are using Jira Cloud, Server, or Data Center.  If Cloud, I have seen rule performance be inconsistent, even for trivially simple rules.

Perhaps try removing rule steps to isolate where the time is going, and then trying to improve those.

Chris · Answer

Dear @Bill Sheboy Thank you very much for your input. Up until now, I did not unterstand the .split, .match and .first, but I am a big fan of regex. :-) I very much value your inputs about the changelog. As it seems, the webresponse is ordered in a descending way -> newest entries come first. The webresponse from my current test ticket has 4000+ lines and I can still find all state-changes. I am confident, that the newest one should be available anyway, but I will try to implement a default behaviour, if no previous state could be found. (Trigger for my automation will be "comment created".) My integration provider suggested a solution using .substringBetween to parse the webrequest response. All your inputs got me going and I tried many different things. Regex to get the state-change history entries To get a list of all state changes from the history, I found this: {{response.match("((?=\{field=status)\{field=status, fieldtype=jira, fieldId=status, from=\d*, fromString=(([\w\s]*)|(\w)*), to=\d*, toString=(([\w\s]*)|(\w)*)\})")}} This will result in something like this: {field=status, fieldtype=jira, fieldId=status, from=3, fromString=In Progress, to=10006, toString=Warten auf Kunden}, {field=status, fieldtype=jira, fieldId=status, from=10006, fromString=Warten auf Kunden, to=3, toString=In Progress}, {field=status, fieldtype=jira, fieldId=status, from=10005, fromString=Pendent, to=10006, toString=Warten auf Kunden}, {field=status, fieldtype=jira, fieldId=status, from=10016, fromString=Selected for Development, to=10005, toString=Pendent}, {field=status, fieldtype=jira, fieldId=status, from=10004, fromString=in Vorbereitung, to=10016, toString=Selected for Development}, {field=status, fieldtype=jira, fieldId=status, from=10003, fromString=Backlog, to=10004, toString=in Vorbereitung}, {field=status, fieldtype=jira, fieldId=status, from=10016, fromString=Selected for Development, to=10003, toString=Backlog}, {field=status, fieldtype=jira, fieldId=status, from=10003, fromString=Backlog, to=10016, toString=Selected for Development} by adding the .first, I can reduce it to the newest entry. Then, I would have to use .split and .match to read the "from=" or "fromString". Downsides are... * ... the big, long regex. It is designed for your state-names. (-> one word or several words with spaces) and * ... I have to use several steps with .match and .split to get the final result. Regex to get the newest from stateId I then modified my approach a little bit. This line directly provides the list of all from-status from all state-changes. (newest first) {{response.match("((?<=\{field=status, fieldtype=jira, fieldId=status, from=)\d*)")}} Again, by adding the .first, I get the ID I need directly into a variable. {{response.match("((?<=\{field=status, fieldtype=jira, fieldId=status, from=)\d*)").first}} The duration of the processing time is approx. 3-4 seconds. Looking forward to your feedback on this solution. Chris EDIT: the original web response is a JSON. It would be so much easier, if the {{webhookResponse.body}} would be a JSON-object as well. Is there a way to read the response as JSON?

Bill Sheboy · Answer

Here is a follow-up example with that workaround...assuming the answer is in the current response for the Send Web Request action.

* create variable:* name: varHistory
* smart value:

@{{items.from}}~~{{/}}

That would produce a delimited, text string like this:

@10003~~and so on...

* to parse out the status histories' "from" value with the status id, use this expression:

@(.*)")}}

* and you want the most recent one, which should be the first in the list:

@(.*)").first}}