Automate fix versions being added to a work item, based on the work item's sprint date

Danny_qtq7b3

Hello Atlassian Community, 

I have an interesting goal to achieve and I need your help. 

Goal

Using Jira automation, I want to add the correct fix version to a work item when the work item has a sprint added to it. The correct fix version is based on the sprint start and end dates being within the version's start date and release date. 

My progress so far...

• The trigger is easy; when the work item has the sprint value added. 
• The first action is for a web request to look up all versions within the Jira Space to return all version startDate and releaseDate against each version. 
• I pulled the work item's sprint to get the sprint's startDate and endDate via smart values with date dot notations applied. 

The problem

This is where I get to the problem, I have both sets of dates, I want to compare the sprint start dates with all the version start dates and determine which version start dates begin before or at the same time as the sprint start date. At the same time, I would need to do a similar comparison with the sprint endDate and all the remaining viable versions where the release dates is after or the same as the sprint's end date. 

This is the Jira automation smart value logic I am using to no success and debugging with log actions (I am hoping it would return a version ID and name): 

Version is: 
{{#webResponse.body}} 
{{#if(issue.customfield_10020.startDate.jiraDate.isAfter(startDate))}}
{{#if(issue.customfield_10020.endDate.jiraDate.isBefore(releaseDate))}}
{{name}} (ID: {{id}}) 
{{/}} 
{{/}} 
{{/webResponse.body}}

the webResponse.body is from the REST API endpoint I am calling. I have confirmed the JSON is coming through as expected. 

customfield_10020 is the sprint field. As you can see, I have taken the dates and formatted them so they are the same format as the version startDate and releaseDate date formats. 

Currently, the log action returns nothing and I'm out of ideas. 

Any help would be gladly appreciated. 

Thanks,

Danny

 

 

Bill Sheboy

Hi @Danny 

Short answer: This is not easy to solve.

Longer answer: There is a known limitation / defect with long-format list iteration which prevents what you are trying; please see below for details.  Possible workarounds are: investigate marketplace apps to help; build your own external service to solve this outside of Jira, calling the new endpoint with Send Web Request; or use dynamic list searching methods, as I outline in this article.  There is another workaround, which requires an assumption to use branching.

 

The details...

Once inside of a long-format list iterator such as {{#someList}} ...do stuff {{/}} it can only access data from the list scope, and lower.  For your rule iterating over the webResponse, the inside processing cannot access the current work item's fields.  Atlassian knows about this limitation / defect, and my understanding from other posts is they have tried several times to fix it without success.

And also unfortunately, the REST API endpoints to get the project versions do not have query parameters to filter by the version Start Date and Release Date, as that would make this easier to solve.

 

Back to the possible workarounds, listed in increasing order of effort and complexity and risk...

#1) There are probably marketplace apps which can do this, although I have never investigated any of them.

#2) You could write your own external service, using a language with sequential iteration (or filtering) which is not subject to the data scope limitation.  Have it return the desired version ID.

#3) You could use dynamic list searching, with created variables and regular expressions.  The essential steps would be:

• call the endpoint to get all the relevant fix versions
• "flatten" the returned value into a delimited text string, keeping the version ID, Start Date, and Release Date; for example:

id=23,start=2025-12-01,release=2025-12-30;id=24,start=2026-01-02,release=2026-01-30...

• using inline iteration and concatenation, add the Sprint's Start Date and End Date values to each list item (This solves the access problem by making the data self-contained for each list item.)
• using long-format iteration, and possibly math or date / time functions, perform the relevant comparisons, leading to the two Boolean results you tested earlier, storing that new list in a create variable
• build a regular expression which tests the Boolean results, saving it in a created variable
• use inline iteration with the match() function and the dynamic regular expression to extract the matching version(s), probably confirming there is one-and-only-one result
• finally, extract the version ID from the result and set it.

 

#4) This last workaround with branching has two key assumptions:

• you want to only change one work item: the trigger one for the rule
• you know there is exactly zero-or-one version which matches your criteria

If both of those are met, your rule could use advanced branching over each version found in the webResponse, use smart value conditions to test the dates, and the assign the version.  If either of those assumptions are not met, the rule could have collisions updating work items due to the parallel processing of branches.

 

Kind regards,
Bill