Set issues fixed versions automatically

[Paul Dokken]

I just started using Releases and versions in my JSW project.  When I transition an issue to DONE I would like the Fix Versions to be set to the latest unreleased version.  How would I do this?

[Bill Sheboy · Accepted solution]

Hi @Paul Dokken 

You may do that with an Automation for Jira rule.  For example:

• trigger: issue transitioned to Done
• condition: Fix Versions field is empty
• action: edit issue to set the Fix Versions to the "Next unreleased version"

You could remove the condition if you want to replace any existing value.

To learn more about automation rules, please look at these sources and examples:

• https://www.atlassian.com/software/jira/guides/expand-jira/automation
• https://www.atlassian.com/software/jira/automation-template-library#/label/all/1453
• https://community.atlassian.com/t5/Automation-articles/Jira-Automation-all-the-resources-you-need-in-one-page/ba-p/1388465

Kind regards,
Bill

[Paul Dokken]

Perfect!  This is exactly what I was looking for.  Thanks so much for sharing your knowledge.

[Salim Ubeydullah]

Follow up question, 

How can I set the fixVersion not to the next Unreleased version, but to the one right after?

Also, is it possible to read the {{pullRequest.destinationBranch.name}} variable, parse it and dynamicly set the fixVersion?

Example: If the branch is develop, I want to set the version to 1.1.0
If the branch is release-1.0.0, I want to set the version to 1.0.0

[Bill Sheboy]

Hi @Salim Ubeydullah -- Welcome to the Atlassian Community!

The short answer to your first question is: probably not.  Smart value lists do not have the ability to be sorted, and so you cannot find the "one before the next one".

For your second question, the answer is "yes".  A version can be set from the drop-down list or from a smart value expression, and so you would create an expression to get that version number from the branch name to use it.

Kind regards,
Bill

[Salim Ubeydullah]

Thanks, yes I tried the second option and it works.

My third solution is to have a label set on the PR, that matches a release version name in JIRA, grab that and set it as the release version. Is that doable?

is there a smart variable like {{pullRequest.labels}} ?

[Bill Sheboy]

Based on the documentation, those labels may not be available: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-development/#--Pull-request--

However...everything possible is not listed in the documentation.  So I recommend making a test rule which is triggered to access a PR, and then write the contents to the audit log (or email them to yourself) as JSON to see what is available for access.

[Salim Ubeydullah]

Ok, Since Labels is probably an array, what would be a good guess to try to set the fixVersion to all the label, then JIRA will only pick the ones that matches an existing Release name?

[Bill Sheboy]

Did you confirm the labels are available?

And if you are trying to set multiple versions based upon data, such as from the fields, you would need extract the labels, expand the list, and then format them for advanced edit with JSON, as described here: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Fix-Versions

[Paul Dokken]

Here is the audit log.  The 20 that I mentioned should meet the condition that all are transitioned to done and Fix Versions is empty. The reason I have the rule global is I want it to run on both my software projects which each have their own Fix Versions.  

[Paul Dokken]

I thought it was working but has only worked on 2 issues out of about 20 that have already been done.  I have made sure the scope is set for the project.  Any ideas?

[Bill Sheboy]

Hi, Paul.

When you note it only worked on 2 issues out of 20, what are you observing happening? 

Can you post images of the audit log details showing executions where it worked and did not work as expected?

Next, I notice you have set this up as a global scope rule. 

• Is that intentional or do you just need this for one project? 
• The reason I ask is that versions are set up by project, and so I wonder if something in the edit is not working as you expect when versions are not set up for a project.  What I would expect for that case is the Fix Version is cleared in that case.

Kind regards,
Bill

[Paul Dokken]

Hi Bill,

Here is the audit log.  The 20 issues that I mentioned should have met the condition of transitioning to done and Fix Versions is empty to only 2 ran.  

The reason I made the rule global is that there are 2 software projects and each of them have their own Fix versions.  

[Bill Sheboy]

Thanks for that info, Paul.

According to the audit log, the rule seems to be triggering for only one project: FSO.  Were there other issues for that same project which did not trigger the rule?

And, are these Company-managed or Team-managed projects?

I ask because the "Done" status for company-managed project is probably a shared/reused status in your Jira site.  For team-managed, each project has its own set of status values.  So perhaps the rule is not picking up one of them for the project.

If one (or both) projects are team-managed, you can check this by copying the rule to one of the projects, disabling the global rule, and see if the project-specific rule works as expected.

[Paul Dokken]

FSO is a team managed project.  The scope is now just for software projects.  I am wondering if I need to have the Check to allow other rules... checkbox checked since I have an automation that moves the status to to done. 

[Bill Sheboy]

Ah...yes, you do.  The "Allow rule trigger" option does that.  The default is disabled to prevent a runaway rule/looping condition, and in your case you want one rule to trigger another.  Sorry I missed that!