Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,367,335
Community Members
 
Community Events
168
Community Groups

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

Edited
Jarosław Solecki Marketplace Partner Jul 29, 2020

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!

Screenshot 2020-07-29 at 14.46.02.png

1 answer

1 accepted

1 vote
Answer accepted

Hi @Jarosław Solecki 

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 Marketplace Partner Jul 30, 2020

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 Marketplace Partner Jul 31, 2020

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

Like # people like this

Hi @Jarosław Solecki   

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

Jarosław Solecki Marketplace Partner Aug 11, 2020

Here is a linked defect: 

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

Unfortunately, there is no workaround currently.

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.

Like Rahul Jith likes this

Hi @Jarosław Solecki @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

Jarosław Solecki Marketplace Partner Aug 30, 2022

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.

Like Rahul Jith likes this

Thank you for the update @Jarosław Solecki 

Any workarounds you feel working?

Jarosław Solecki Marketplace Partner Aug 30, 2022

Unfortunately, I didn't find it. 

Like Rahul Jith likes this

Hi @Rahul Jith 

Yes, and...to what @Jarosław Solecki 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

Like Rahul Jith likes this

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 

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.

Like Rahul Jith likes this

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

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  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:

                       Capture.PNG 

  • 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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS

Atlassian Community Events