Automation Requirement:
When an existing Release(e.g. 012) "Release Date" is updated
Then update issues that have the same "012" fixVersion and set their due date field to same date as 012 Release Date.
Attempted Automation Solution:
When: Version Updated
[Branch rule} For JQL
fixVersion = {{version.name}}
THEN: Edit issue fields
Due date
{{issue.fixversions.releaseDate.jiraDate}}
ISSUE:
I have tried the above with the branch rule JQL as fixVersion = earliestUnreleasedVersion() and it correctly updated a issues due date for 1 version. So the logic works.
However, that only updates the generic issues in earliestUnreleasedVersion data set.
I wish to update issues where fixversion = {{version.name}} and this returns no result when updating the release date.
I'm guessing this may be because of the possible multiple values in the fixedversions field but can't work out how to deal with this.
Can anyone advise please?
Hi @Bill Sheboy - that cracked it thanks! That one was in the back of my mind but couldn't quite recall it!
Can you also advise these related slightly trickier questions:
If an issue (in the above data set) has multiple fixversions how would I only update the issues where the fixversion being updated is:
1) the latest release date (of the fixversions on that issue)?
2) the earliest release date (of the fixversions on that issue)?
Hi, Christopher!
Luckily you are using the Cloud version so those things are possible as you only want the Release Date. The fixVersion field is a list, and so the technique is to pull apart the release attributes into a created variable, and then use the list functions min() or max() to get the data you want. For example:
{{#issue.fixVersions}}{{releaseDate.jiraDate}}{{^last}},{{/}}{{/}}
{{varReleaseDates.split(",").toDate.max}}
{{varReleaseDates.split(",").toDate.min}}
Note well: created variables, just like issues have scope. So create your variable outside of any branches you want to use them in. Otherwise the asynchronous processing of automation rules will create new variables repeatedly, making them useless.
Please let me know how this works out for you. Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bill - took me while to find you have to create the var as null (outside branch as you described) and then create the var again within the branch with the current issue's values but got there and its working fine.
Screen shot on the approach enclosed for any newbies like me.
Working like a treat and and a great learning for my first automation so thanks very much; appreciate the help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Awesome! I am glad to learn you solved it. For reference on some nuts-and-bolts details...
Here is the article describing usage of created variables before/inside branches: https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Create-variable-New-component/ba-p/1448118
At the time that article was written, one key behavior is when a branch can evaluate to one-and-only-one issue (at design time), it becomes inline code and so the variable "trick" works. But if the branch returns (or could return) more than one issue, there is no guarantee what the final variable value will be. This is because each branch loop fires off independently, runs, and completes. There isn't even a guarantee that the branch will complete before the next steps after it in the rule.
The work-around some people do for this is to use created variables and entity properties together, persisting the values.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Christopher -- Welcome to the Atlassian Community!
Have you tried to match on the {{version.id}} value instead with JQL of
project = myProject AND fixVersion IN ( {{version.id}} )
If that does not help, please post an image of your rule and of the audit log from an execution that does not work as expected. Thanks!
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.