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.
Hi @Emre_Bolcakan -- Welcome to the Atlassian Community!
First, some questions to help focus your scenario:
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.