nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation: Assigning Fix version based on release date

unknown

Hello everyone,

I'm trying to create an automation rule or improve existing transition rules by including a solution to auto-assign fix versions to my tickets. Due to the way release versions are structured within my project, I'd like to do this by comparing the current date to the release version start and end date, and selecting the correct release version accordingly.

Accepted answers

Bill Sheboy

Hi @[deleted]-- Welcome to the Atlassian Community!

First, some questions to help focus your scenario:

When do you want to assign a specific release to the Fix Versions for a work item?
How do select the work items for which to perform this assignment?
What would happen when there are no releases for the current time frame, or no releases with configured dates?
What would happen when there are multiple releases with the current time frame?

Until we know the answers to those questions...

Assuming your releases are in order and their status is current, you might be able to just assign the work items to the Next Unreleased Version using the Edit Work Item rule action.

But if not...

To get the information about the releases, an automation rule would need to call the REST API endpoint to load their information using the Send Web Request action. The releases could be filtered to only return the ones matching your criteria, such as name, status, etc.

The challenging part will be identifying the correct version by date. If this is always relative to the current date, {{now}} could be used to help with filtering. If another date is used, this scenario is much more difficult to solve.

If you want to experiment with this approach, here is a how-to article for calling a REST API endpoint from a rule: https://community.atlassian.com/forums/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

Kind regards,
Bill

All comments

Bill Sheboy

Hi @[deleted]-- Welcome to the Atlassian Community!

First, some questions to help focus your scenario:

When do you want to assign a specific release to the Fix Versions for a work item?
How do select the work items for which to perform this assignment?
What would happen when there are no releases for the current time frame, or no releases with configured dates?
What would happen when there are multiple releases with the current time frame?

Until we know the answers to those questions...

Assuming your releases are in order and their status is current, you might be able to just assign the work items to the Next Unreleased Version using the Edit Work Item rule action.

But if not...

Kind regards,
Bill

unknown

Hi Bill, thanks for your response.

1. It's a condition for an exiting transition rule. When the issue is transitioned, the fix version should be assigned. To answer question 2, it should affect issues when this rule is triggered.

3 and 4. My project has recently always had release versions with the start and end date specified. Sadly past release versions are very much not in order, I had tried using Next Unreleased Version and it took a very old release version. I think I will create another post for an automation rule to bulk release all the old versions, as we have hundreds of releases that have not been released and some of which don't have the start and end date for the sprint.

Bill Sheboy

Thanks; that information helps. I recommend cleaning up the older versions before proceeding to get them out of the way of your new rule.

What do the dates look like in your release list? For example, are they set up on a cadence (e.g., weekly, monthly, etc.) or they have no defined pattern?

If there is a cadence / defined pattern, it should be easier to find the correct release from the results of the REST API call. Otherwise finding the correct one is quite difficult, as I noted earlier.