Adding Fix version to a Bug / Story.
When triggered (value added to Fix version field) and checked (for Bug / Story)
If fixversion changed from empty
For Sub-tasks
If status != done
Copy Fix version from trigger issue
Else
For each smart value (reading the added Fix version(s) from the changelog)
Create new Sub-task
The rule never enters the Else branch even if the Fix version Field is in fact empty when I add a version, it always enters the If branch.
I've tried using the Was operator as well ("fixversion was empty") but that doesn't work either but as far as I can tell that's to be expected when using Was, as Was looks at the entire history of the field. Is that true for Change as well? I e if the field at one point in history was empty (which is almost always the case in my scenario) the rule will never enter the Else branch? If so, how do I set up the rule to accommodate my scenario?
{{issue.fixVersions.size}}can given the number of fixVersions present on the issue
if 1 a new fixVersion is added.
if > 1 then more than one fixVersion
if 0 then all fixVersion is removed
From documentation, looks like below may not work for list of fixVersions
{{fieldChange.fromString}}
Added a smart value / variable to the main branch using {{issue.fixversions.size}} ("nrOfFixVersions").
If {{nrOfFixVersions}} = 1
[...]
Else-if {{nrOfFixVersions}} is greater than 1
If the Fix version field is empty and I add one version nothing happens, If {{nrOfFixVersions}} = 1 doesn't catch it. Though I print the variable after creating it and it reads 1.
Continuing and adding a second version, the Else-if branch catches it and creates a new Sub-task with the second version (correct behavior).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you create the variable before the if block
When i try like this, it is entering the if block when first fixVersion is added
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.
I again ran my automation my audit log shows match when 1st fixVersion is added.
There seems to be a case mismatch in fixversions. Can you use fixVersions and try with that?
Additionally, do below
when creating smart Variable, in smart Value, put like this
{{#debug}}{{issue.fixVersions.size}}{{/}}
It will print the value assigned to nrOfFixVersions in audit log. there is a case
And in if matches, use
{{nrOfFixVersions.asNumber}}
Let's see how it goes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What do you mean by mismatch in fixversions? Not sure what you want me to try here, but with
{{#debug}}{{issue.fixVersions.size}}{{/}}
and
{{nrOfFixVersions.asNumber}}
I e If: matches{{nrOfFixVersions.asNumber}} = 1
Correct?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Could you suggest why the rule is not working in Martin's instance while it is working in my cloud instance?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Martin Karlsson and @Vishal Biyani
For Jira Cloud, there are long-standing defects / inaccuracies with the changelog for list fields (e.g., Fix Versions, Affects Versions, and Sprints) which is available to automation rules. These symptoms can clearly be demonstrated using the built-in smart values that should specifically show the added / deleted values but do not: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--fieldChange--
These symptoms worsen dramatically when the values in a field for a specific issue are changed multiple times.
My personal hypothesis: the additional hide / show values code logic for those fields related to UX presentation is somehow co-mingled with what is used for these automation changelogs.
The only way I know to solve this in a rule is with the REST API endpoint (get issue with expand=changelog) for the changelog and directly interpreting the results:
I recall doing this a few years ago to solve the same challenge for the Sprint field.
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.
Given what you've said before I was afraid that might be the issue. I'm hardly the most qualified to speak to this but it does strike me as somewhat odd that issues like this are allowed to go unaddressed for so long, given how central these fields are to Jira's functionality.
Thanks for the support @Bill Sheboy yet again much appreciated.
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.