nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Type/value of {{fieldChange.toString}} for 'fixVersion' varies if the issue is created by cloning

Chris Couldridge

Hello community.

I am creating a rule that is triggered when a 'fixVersion' is added to or removed from an issue using the 'Field value changed' trigger.

It uses the smart value in {{fieldChange.toString}} for the 'fixVersion' field and this works well if someone is manually adding or removing a value on an existing issue, for example in the screenshot below the log is outputting the value of:

fromString: {{fieldChange.fromString}} / toString: {{fieldChange.toString}} / to: {{fieldChange.to}}

Screenshot 2024-03-04 at 12.37.35.png

Here you can see that 'fromString' is empty 'toString' is the name of the version and 'to' is the numeric id of the release.

However if a ticket is cloned and it already has a 'fixVersion', the rule is being triggered, but the smart value output types are different - what is Version Bean?

Screenshot 2024-03-04 at 12.41.38.png

Is this a bug?

As you can see from the second log action I could use the value of the 'fixVersion' field but will show all fixVersions if there were multiple - I only want to target the one that has just been added or removed.

Has anyone else experienced this issue and resolved it? Is this a bug that can be raised and prioritised for fixing?

Thank you in advance

Chris

Accepted answers

All comments

Bill Sheboy

Hi @Chris Couldridge

First thing, for a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Until we see those...

That error message is from the underlying code, with some exception for the Java Bean processing.

There are several known problems with the change log and list fields like Fix Version, Affects Versions, and Sprint...where the change log is not accurate when the field changes over time, and in different conditions. Here are a couple of examples:

https://jira.atlassian.com/browse/JRACLOUD-80486
https://jira.atlassian.com/browse/AUTO-615

It is also possible the rule structure / usage has a timing problem, leading to that error message. Seeing your complete rule and knowing how it is triggered (i.e., through a user action or another rule), may help to explain this symptom.

Kind regards,
Bill

Chris Couldridge

Hi @[deleted]thanks for the quick reply.

The rest of the rule is quite big, and not especially relevant to the problem, but here is the rule up to the point where the problem is seen in the log output:

Screenshot 2024-03-04 at 16.22.46.png

The second and third modules are just some parameterisation of values. The fourth component is where the log output comes from. I'm just outputting the field's changed values for debugging purposes.

You can see in the subsequent log output that the fixVersion name and id are presented as string and number correctly

Screenshot 2024-03-04 at 12.41.38.png

The problem occurs when an existing issue with a fixVersion is cloned, this rule is being triggered by the cloning action, and this is where the Java Bean problem is seen. When a human user manually adds a fixVersion via the UI this problem is not seen. So at the moment this is the scenario/process:

An issue with a fixVersion is cloned - the cloned issue inherits the same fixVersion
The rule runs but errors because the fixVersion name is not output as a string
So the user goes in to the issue in the UI and removes the fixVersion
They then manually re-add it; this time the rule runs again and is sucessful.

This behaviour is consistent, not intermittent or sporadic.

From your description it feels like a timing issue because during the cloning process the output is wrong but after the ticket is cloned and manually updated the output is as expected.

I hope that helps clarify the problem?

Chris

Bill Sheboy

Thanks for those details, Chris.

There are rule triggers which run so quickly that some issue data is not yet available for rule processing. One example is the Issue Created trigger.

I find it interesting this rule is triggered after a manual clone action, and my testing confirms what you see: the issue is created (i.e., cloned) and then the fix version is set separately. This symptom definitely happens for some things, like issue linking after create, but this one surprises me. Seems like Atlassian could improve documentation about which fields are set after the issue is created. Regardless...

The fix / work-around for this type of race-track error is to always include the Re-fetch Issue action immediately after the Issue Created trigger. That slows down the rule, reloading the issue data before proceeding with the other rule steps.

Please try adding the Re-fetch Issue action immediately after your rule trigger and re-test to see the impact.

Chris Couldridge

Ah amazing, thank you very much for this. I will try the re-fetch action (I wasn't even even aware of this action) and post back to let you know what the effect was.

Jörn Bungartz

I solved this by creating a variable as an intermediate step.

When the String "VersionBean" is found in the fieldChange.toString, a regular expression is used to find the version name. Otherwise, the value of fieldChange.toString is used directly:

Here the expression for reference:

{{#if(fieldChange.toString.indexOf("VersionBean").gte(0))}}{{ fieldChange.toString.match("name='([^']+)'")}}{{/}}{{#if (fieldChange.toString.indexOf("VersionBean").lt(0))}}{{ fieldChange.toString}}{{/}}

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud