How do you dynamically parse the returned {{changelog}} string in Automation rule?

[Michelle S]

I want to notify certain people of any changes to any fields in the child work items of an epic.  I was trying to use {{changelog}} but wanted to parse the data to it returns:

• Field:
• Old Value:
• New Value:

without having to pick the field, I want to extract the triggered field(s) from the response.

Examples of changelog values returned for Acceptance Criteria and Description:

Field: {Acceptance Criteria=[ChangeItemBean{fieldId='customfield_10083', field='Acceptance Criteria', fieldType='null', from='', fromString='Acceptance Criteria test', to='', toString='Updated Acceptance Criteria test'}]}

Field: {description=[ChangeItemBean{fieldId='description', field='description', fieldType='null', from='null', fromString='Description text', to='null', toString='Updated Description text'}]}

I found this old article and was excited to see if there was a solution, but it was asked to create a new quesiton which I didn't find so creating this new question.

https://community.atlassian.com/forums/Jira-questions/Have-any-recommendations-for-parsing-the-changelog-string-in/qaq-p/2332771

Thanks!

[Bill Sheboy · Accepted solution]

Hi @Michelle S 

Short answer: that is not easily possible (or even a complete solution) with automation rules.

First thing, every possible thing that can change in a work item is not recorded in the changelog provided to automation rules.  The two reasons for this are: app errors, and marketplace apps / addons.

• Some types of fields do not consistently load values in the {{changelog}} smart value.  One example are list fields such as Sprint and Fix Versions, which can be missing values.  A workaround for this is to ignore the {{changelog}} smart value and directly call the REST API to get the actual changelog, parsing out the most recent entries.
• For marketplace apps / addons, some do not write changes in the log, and instead have their own separate changelog.  An example of this is some checklist apps.  While others store their data elsewhere, and perhaps only have changelogs via REST API calls to their tools.

Next, you show an example with the Work Item Updated trigger.  Although that will detect many things, it will not detect the ones which have a different event.  And so multiple rules would be needed for those additional cases, such as:

• work item created
• work item transitioned to a new status
• work item deleted
• work item assigned...

Please review the list of all possible triggers and experiment to learn which ones the automation engine covers (or does not cover) for "work item updated".

Finally, and as you observed, the content / behavior of the {{changelog}} smart value varies by field, field type, and sometimes even project (e.g., JPD has its own type of date field).  Thus, special handling would be needed for each possible, expected field.

Okay, what could you try?  Here are some ideas:

Keep using the {{changelog}}

• Save the entire {{changelog}} to a Created Variable.  This captures it at a moment in time as text.
• Using text functions to parse out the field(s), and changes.  This will require experimentation to learn what happens for different changes / fields.
• Create some "canary" test rules to detect when Atlassian changes the underlying structure of the changelog in a way that will break your reporting.  This is needed as there are far too many sources to monitor to know when this happens.

Ignore the {{changelog}} and get the real data

• When a work item has changed, call the REST API to get the actual changelog records
• Experiment as above to learn how to parse out what is needed

Investigate marketplace apps for traceability

• There is no doubt marketplace vendors have already done the research to understand what the changelogs contain, and so...
• Investigate those products to have them parse out the changes for reporting

Kind regards,
Bill

[Michelle S]

Thanks @Bill Sheboy ! I will try these different approaches and see what works best.

I was hoping to get:

• Description
• Status
• Acceptance Criteria
• Comment (which I would need to do another rule, and I already know what rule to use here)

Luckily, don't need Fix Version or Sprint. So I think I will try changelog for the first 3 and comment creation using another rule

[Bill Sheboy]

Thanks for clarifying, @Michelle S 

For those fields, you will need three rules, triggered on:

• work item updated (for Description or Acceptance Criteria)
• work item transitioned
• work item commented

[Michelle S]

I literally did just that but I made 4 rules - split the first one in 2.  For any other native fields supported by changelog, I will just copy that rule and update the triggered field.

• work item updated (for Description)
• work item updated (for Acceptance Criteria)
• work item transitioned
• work item commented

[Bill Sheboy]

One more thing...I recommend adding a "label" to the four rules when in the list (or name them in a way to associate them).  This will help with maintenance, tracking problems, and to explain the rule set to other people.

Happy rule writing!

[Michelle S]

What a great idea? Done! :D