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

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?

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

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

[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:

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

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:

1. An issue with a fixVersion is cloned - the cloned issue inherits the same fixVersion
2. The rule runs but errors because the fixVersion name is not output as a string
3. So the user goes in to the issue in the UI and removes the fixVersion
4. 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.

[Chris Couldridge]

I tried the re-fetch action in the rule and then output the values of again, and I still get the same problem.

In the end I took a different (hacky) approach and used the creation time of the ticket to determine whether the issue was a clone, and used if/else to carry out different actions

[Bill Sheboy]

Hmmm...that may not always work due to coincidences of other issue creation timing (and Atlassian service outages ;^)  I recommend keeping a close watch on that rule.

But the way, when I tried adding the Re-fetch after the Field Value Changed trigger for the clone scenario, it worked.  So this may still be the first problem noted about the changelog accuracy.

[Chris Couldridge]

Yes I appreciate this is a hack, but it's better than the rule failing every time an issue gets cloned.

Re: your second point, is there a way to get this notified as a possible bug?

[Bill Sheboy]

In my opinion, the racetrack effect is a design problem / result of how the automation engine uses of the REST API functions.  I have found no open defects for this in the public backlog, although I have suggested that Atlassian fully document which issue fields are set in two steps when issues are created / cloned:

• issue created / cloned
• then set the fields which could not (or were not) set with the previous step

That would at least ensure customers can adjust rules to add the Re-fetch Issue action when needed.

UPDATE: I found a related suggestion, and it appears to be in progress of work.  Although it appears to be a mitigation and not a solution to the root cause.  Please watch / vote here to see progress: https://jira.atlassian.com/browse/AUTO-238