Jira Automation: Transition issues from released version to the latest unreleased version?

[Adam Betz]

When I release a version from the UI, I am prompted with an option to move all unresolved issues to another version (or ignore them and leave them as they are):

I want to create some automation that will provide similar functionality. Currently, I have a rule created to run on a schedule (every 2 weeks) that will create a new version, and then release the previous unreleased version (the default options for that action).

I'm struggling at trying to figure out how I can query all issues with fixVersion matching the just released version, and then assign them the fixVersion for the newly created ones.

I tried to create a JQL Branching statement, but I don't seem to be able to use a Jira smart value in my JQL statement.

Any ideas on how I can expand my current rule to accomplish this? Or possibly, with the aid of a secondary rule that triggers on version creation?

[Mark Segall]

Hi @Adam Betz - I would approach it like this:

• TRIGGER: Scheduled (every 2 weeks)
• ACTION: Release Version
• ACTION: Create Version
• BRANCH (JQL)
  • fixVersion IN releasedVersions() and resolved IS EMPTY
  • ACTION: Edit Issue (Fix versions)
    • {{version}}

This should release the version, create a new version and then find all open issues still attached to the most recent release and change their fix version to the newly created version.

[Bill Sheboy]

Thanks, @Mark Segall 

I like that approach better than mine finding the issues first.

Wouldn't the edit just use "next unreleased version" rather than a smart value?  I believe the {{version}} smart value would only be available with a version-related trigger.

Kind regards,
Bill

[Adam Betz]

@Mark Segall : Thank you for your suggestion!

I actually stumbled onto this solution shortly before your suggestion, and forgot to follow up to this post right away. I was originally unaware of the version-related functions provided by JQL. Once I discovered the fixVersion IN releasedVersions() functions, I created my rule almost exactly the same way you had described it here:

Trigger:

• Schedule (every 2 weeks)

Actions:

• Create version
• Release version
• Branch JQL:
  • JQL: Project in (myProject) AND Resolution is EMPTY AND fixVersion in releasedVersions()
  • Actions: fixVersion = next unreleased version by release date

@Bill Sheboy : Yes, the edit fields action makes it convenient with options like "next unreleased version" and "next unreleased version by release date" options. Before I realized I had those, I was trying to reverse-engineer my own variation of this by creating a variable in my rule that was a delimited-list of all unreleased version in my project, and then finding the next unreleased version by release date via a string manipulation trick, and then manipulating THAT version sub-string to pull out things like the version name and start date I wanted, and then ... in short, it got messy and complicated. After trying this for several hours, I discovered that Jira makes what I was spending a lot of energy and effort on easy ... and then I felt silly 😂. 

Thanks to both of you!

[Bill Sheboy]

Yup, that technique was needed earlier with automation rules...until those options were added for setting the Fix Version field.

Of note for using this approach: I recommend running a basic query before using this to look for any "orphaned issues" which are assigned a released versions and not resolved.  Those could be leftovers from earlier work...and you may not want them accidentally bundled the first time this rule runs.

[Mark Segall]

Yes - I totally over-complicated the solution with the {{version}} smart tag.  I forgot that you can set it to next release version by date.

[Bill Sheboy]

Hi @Adam Betz 

For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected.  Those will provide context for the community to offer ideas.  Thanks!

Until we see those...

What is your rule trigger?  Is it scheduled as you describe in part of the question?

If so, and assuming there are always issues assigned to the next, unreleased version:

• Before you release the version...you could use the Lookup Issues action with JQL to identify the incomplete issues involved, using the JQL function earliestUnreleasedVersion() https://support.atlassian.com/jira-software-cloud/docs/jql-functions/#earliestUnreleasedVersion--
• Release your old version
• Create your new version
• Using an advanced branch on the lookup issues results for only the incomplete items
  • Edit your issues, setting the fix version to the next, unreleased version

Please note, the release will happen with the issues still present, and the edit later removes them.  So if you have any other rules based on the release happening, that would need to be investigated.

Kind regards,
Bill