Automation - How to print changelog for Smart values like "components" from triggered issues?

[Jarosław Solecki [Deviniti]]

Hi, 
I am trying to set notification about changes on related issues. 

I succeed to get the previous and current value for Summary and Description and few other fields but I can't do the same with Fix Version and Components.  

Here are the values I am trying to use. 

{{#changelog.fixVersions}} Fix Version has changed from "{{fromString}}" to"{{toString}}"{{/changelog.fixVersions}}

{{#changelog.component}} Components was removed "{{fromString}}" Component was added "{{toString}}" {{/changelog.component}}

Unfortunately, it doesn't work. Does anybody have the same problem?

Thanks for the help!

[Bill Sheboy · Accepted solution]

Hi @Jarosław Solecki [Deviniti] 

Did you notice that the fields not working for you, Components and Fix Version, are both list fields?  I did some rule testing and what I saw was:

• Components sometimes worked
• Fix Version never worked, even when using fixVersion.name to go inside the item
• And Labels always worked

There seems to be a defect (or undocumented behavior :^) for changelog and list field processing.  Until someone from Atlassian who worked on this (former CodeBarrel folks) comments, I suggest submitting a defect through your JIRA instance admin:

https://support.atlassian.com/contact/#/

Best regards,

Bill

[Jarosław Solecki [Deviniti]]

Hi @Bill Sheboy ,
I noticed that with list fields but Labels also shouldn't work then. 

Thank you for your reply. I also assume that this is some kind of bug which I will report. 

[Jarosław Solecki [Deviniti]]

I reported that as a bug and Atlassian confirmed that. :)

[Bill Sheboy]

Hi @Jarosław Solecki [Deviniti]   

When you hear back on the defect disposition, would you please post the info here?  Thanks!

[Jarosław Solecki [Deviniti]]

Here is a linked defect: 

https://codebarrel.atlassian.net/browse/AUT-2013

Unfortunately, there is no workaround currently.

[Bill Sheboy]

Thanks for the update and the link to the defect...  Unfortunately there isn't one place to look for these issues (or documentation either :^) Some are in the old Code Barrel backlog (AUT) and others are in the public Atlassian Cloud backlog.  And neither shows the complete list of open known defects.

Hopefully both will improve over time so there will be less guess work and experimentation to use the automation rules.

[Rahul Jith]

Hi @Jarosław Solecki [Deviniti] @Bill Sheboy ,

Hope you are doing well

Is this issue sorted? If so, can you assist with the updated code. I  am getting the same issue.

Rahul Jith

[Rahul Jith]

@Jarosław Solecki [Deviniti] @Bill Sheboy 

[Jarosław Solecki [Deviniti]]

Didn't check in Jira but the Jira ticket is still open (https://codebarrel.atlassian.net/browse/AUT-407) so probably we still need to wait for that.

[Rahul Jith]

Thank you for the update @Jarosław Solecki [Deviniti] 

Any workarounds you feel working?

[Jarosław Solecki [Deviniti]]

Unfortunately, I didn't find it. 

[Bill Sheboy]

Hi @Rahul Jith 

Yes, and...to what @Jarosław Solecki [Deviniti] notes:

{{fieldChange}} and {{changelog}} have values when there is an issue change, as captured by an automation rule trigger.  With your scheduled trigger those smart values would always be empty as there was no issue change event: just a time-based one.

Updated: below may not work...

To do what you are trying without issue changes, you may need a more complex rule: repeatedly calling the REST API with a web request to get the issues' change history and then parse that response to find changes to the fixVersion.  I have not tried a rule to do this for version history, and I suspect the regular expression to pull out the data will be complicated.

Kind regards,
Bill

[Rahul Jith]

Hi @Bill Sheboy ,

Thanks for the support as always 😊

I have kept a lookup which captures the issue changes in last 7 days,(2nd rule in my screenshot) which is printing me the correct issues which are changed(2nd attachment). But, my main intention is to print this issues along with the details of the fix version changes.(from and to).

Going through your email one doubt arise in my mind that if I keep that lookup condition within the scheduled as a query will this issue be resolved. (Deleting the action in Lookup).

Regards

Rahul Jith 

[Bill Sheboy]

Sorry if I was unclear:

• that rule change will not help you get the value for the previous/from value of fixVersion.  Here is why...

When a field changes, an event is raised: "hey, this field changed!".  That event can be used to trigger a rule because the rule is "watching" for that event.  For example with an Issue field changed trigger.

The history of changes is recorded with each issue.  And so JQL can be used to detect changes over time...like in your JQL statement with the lookup action.  But this JQL ability is generic, and it cannot report the prior and current value: only the current value.

And so any automation rule triggered on a schedule (with or without JQL) cannot see the previous value of fields.  This is why the change smart values are empty in your rule: the changing field did not trigger the rule.

I recommend pausing to consider what problem are you trying to solve.  It may be sufficient just to identify the issues, their current fixVersion, and then review them for the fixVersion changes.

[Rahul Jith]

Hi @Bill Sheboy ,

Absolutely agree with you. It was a blunder I did with the scheduler as trigger. Yes I totally understood the reason. Thank you so much  Bill on detailing it and make me understand. Much appreciated on your prompt support. 

Now with the trigger as issue field value changes, I have tried with changelog and fieldchange options and still getting a blank outcome.

Below are the tested failed scenarios

 1.

{{#changelog.fixVersions}} Value updated from "{{fromString}}" to "{{toString}}"{{/changelog.fixVersions}}

2.

{{fieldChange.field}} field was updated from {{fieldChange.fromString}} to {{fieldChange.toString}}

3.

Changed value- {{triggerissue.fixVersions.name}}

Changed from- {{fieldChange.fromString}} 

All the above 3 failed to print the fixversion change history. kindly advice if any workarounds can sort this issue.

My requirement is any changes to fix version should be notified with old version details and new version details. 

Regards

Rahul Jith

[Bill Sheboy]

Short version: this may not be possible with an automation rule due to the way the REST API captures changes to a list field.  This seems to be the specifics of the defect @Jarosław Solecki [Deviniti]  noted in this thread.

Longer version:

• I retested with Jira Cloud, using several scenarios of add/remove, and single/multiple values of fixVersion
• In an automation rule, the {{changelog}} smart value was not consistently able to access the previous value for fixVersion
• In an automation rule, the {{fieldChange}} smart value was not consistently able to access the previous value for fixVersion
• Calling the REST API for change logs (issue history) seems to explain why rules have difficulty...
  • The adds and removes from a list field are logged separately.  For example, changing one fixVersion for another creates 2 entries:

                        

• one entry shows From: old value and To: null
• another entry shows From: null and To: new value
• the entry order seems inconsistent, and not one predictable order, such as remove then add
• Other types of field changes seem to only create one change log entry
• And so perhaps automation rules only ever look at the first change log entry found

I am unclear how a rule could be written to aggregate/summarize the multiple change log entries for the reporting you want: it would need to handle 1-to-many possible change entries.

[Janusz Bułakowski]

Hello guys, I've got the same issues. If there are multiple I could not get the last fix versions of the issue. :( Any came up with the fix or workaround?