Jira automation: Check whether a version is already released when an issue is assigned to it

[Nick de Palézieux]

I'm trying to write a pretty simple automation rule: When somebody sets the "Fix Version" on an issue to a version that is already released, warn them that this should not be done.

I have an automation set up to trigger whenever a value is added to the Fix Versions field.

I'm struggling to check the {{released}} attribute of the smart value. I would have expected that {{fieldChange.to.released}} works. But it doesn't. I can get the ID and the name of the version, but not any of its attributes (see screenshots below). How can I write a condition based on whether the version that was just added is released or not?

Thanks for your help

[Ste Wright · Accepted solution]

Hi @Nick de Palézieux 

There might be a more elegant method of doing this using Fix Version smart values, but I did it using a JQL Condition:

• Trigger: Field Value Changed
  • Field to Monitor = Fix Versions
  • Change Type = Value Added
• Condition: JQL Condition
  • JQL - fixversion in releasedVersions()
• Action: As required

Let us know if this helps!

Ste

[Nick de Palézieux]

This looks like it would work if I could make the assumption that there is just one version in fixVersions. What happens if there are multiple?

[Ste Wright]

I'd consider setting the "Change Type" of the Trigger to "Value Added".

That way, if a Fix Version is added (making for multiple versions), it could alert the user that the last Fix Version added was in a released state, or one of the last Versions added was.

Ste

[Bill Sheboy]

Hi @Nick de Palézieux 

There are known problems with automation rule parsing of the change log and list fields, particularly versions.  Here are a couple of them:

https://jira.atlassian.com/browse/JIRAAUTOSERVER-207
https://jira.atlassian.com/browse/JRACLOUD-81160

And so you may get a rule which appears to work, but its results may not be consistent.

Let's assume your rule can be accurately triggered and that {{fieldChange.to}} can accurately return a list of version id values.  In that case, you could use either:

• The Lookup Issues action to gather issues with the id(s), grab the distinct versions, and then test the released attribute.  This is a variation of what Stephen suggested.
• Call the REST API with a Send Web Request action to get all the versions, filter for yours, and then check the released attribute

Kind regards,
Bill

[Nick de Palézieux]

That's valuable information, thank you!

I ended up implementing basically what @Ste Wright suggested, although I guess it's not going to be super reliable.

[Murat Seven]

Hi @Nick de Palézieux 

Have you tried this smart value?

{{issue.fixVersions.released}}

[Nick de Palézieux]

This might work if I could make the assumption that there is just one version in fixVersions. What happens if there are multiple?

[Murat Seven]

In this case, you can use the 'create variable' action. you can create a variable as shown in the screenshot I've provided and utilize it within the condition.

[Nick de Palézieux]

And what would you put in the "Smart value" input field for the "Create variable" action?

[Murat Seven]

[Nick de Palézieux]

Thanks for your reply. I don't understand how creating a variable first fixes the ambiguity when there are multiple versions in the Fix Versions field (e.g. if there is one already and a second one is added).

Will the {{fixVersionReleased}} field always contain the one that was just added?

[Murat Seven]

Hi @Nick de Palézieux  

Yes, to provide an example using an issue: if fix version that had been previously released is added to the issue, you can detect this through the variable we've created. I'm sharing the details of the automation rule and the audit log screen below. With this condition, if a previously released value is added, the automation can perform actions accordingly.