Fix version change from empty condition disregards the fields status (?)

Martin Karlsson
Contributor
February 18, 2025

Scenario

Adding Fix version to a Bug / Story.

  • If the Fix version field is empty I want the added version copied to the Bug's / Story's Sub-task.
  • If the Fix version contains at least one version already, I want a new Sub-task to be created inheriting the added version (one for each version if several were added).
  • I don't want to take time (say changes to the field the last week or between dates x and y) or whether the field was empty or not at some earlier point in time into consideration, just whether the field was or was not empty before the change triggering the rule.

My rule

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

rule.png

Problem

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?

Results with an empty Fix version field when adding a version

no_fix_version.png

Result with a version already in the Fix version field when adding a new version

 

fix_version_exists.png

1 answer

1 accepted

0 votes
Answer accepted
Vishal Biyani
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 18, 2025

@Martin Karlsson 

{{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}}

snip.png

Martin Karlsson
Contributor
February 18, 2025

Hi @Vishal Biyani 

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.png

else-if.png

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).

 

Vishal Biyani
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 18, 2025

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

snip.png

 

 

Martin Karlsson
Contributor
February 19, 2025

Still doesn't work.

Skärmbild 2025-02-19 111028.png

Skärmbild 2025-02-19 111335.png

Vishal Biyani
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 19, 2025

I again ran my automation my audit log shows match when 1st fixVersion is added.

snip.png

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.

 

Martin Karlsson
Contributor
February 19, 2025

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?

 

 Skärmbild 2025-02-19 122928.png

Vishal Biyani
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 19, 2025

@Bill Sheboy 

Could you suggest why the rule is not working in Martin's instance while it is working in my cloud instance?

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 19, 2025

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:

  • get the changelog for the issue with the Send Web Request action
  • parse the last entry, for the Fix Versions field, examining the "from" / "to" (or "fromString" / "toString") values directly
  • decide what to do...

I recall doing this a few years ago to solve the same challenge for the Sprint field.

 

Kind regards,
Bill

Like Vishal Biyani likes this
Martin Karlsson
Contributor
February 19, 2025

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events