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

[Martin Karlsson]

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

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

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

[Vishal Biyani · Accepted solution]

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

[Martin Karlsson]

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 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]

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

[Martin Karlsson]

Still doesn't work.

[Vishal Biyani]

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.

[Martin Karlsson]

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?

 

[Vishal Biyani]

@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]

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

[Martin Karlsson]

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.