The API response contains two locations where the same value exists:
In the customFields definition object.
In the virtualVersions.customFields map, where the key is the custom field ID.
Example structure from the response:
"customFields": [
{
"id": "69a18668c0386b0f42a6cbb5",
"options": [
{
"id": "69a1866ec0386b0f42a6cbb6",
"label": "yes"
}
]
}
]And in the virtual version object:
"virtualVersions": [
{
"id": "694561558c4ed6a5f5230139",
"customFields": {
"69a18668c0386b0f42a6cbb5": "69a1866ec0386b0f42a6cbb6"
}
}
]So the option ID (69a1866ec0386b0f42a6cbb6) appears in both places.
To extract the option ID for label yes:
{{#webResponse.body.customFields}}
{{#if(equals(id,"69a18668c0386b0f42a6cbb5"))}}
{{#options}}
{{#if(equals(label,"yes"))}}
{{id}}
{{/}}
{{/options}}
{{/}}
{{/webResponse.body.customFields}}To extract the value from the virtual version:
{{#webResponse.body.virtualVersions}}
{{#if(equals(id,"694561558c4ed6a5f5230139"))}}
{{customFields.69a18668c0386b0f42a6cbb5}}
{{/}}
{{/webResponse.body.virtualVersions}}Both values appear identical in logs:
69a1866ec0386b0f42a6cbb6However, when I use an Advanced compare condition:
{{value1}} equals {{value2}}the condition fails.
I tried several approaches to normalize the values:
.trim
.asString
.asJsonString
storing values in variables before comparing
checking for hidden whitespace
using .toString
None of these resolved the comparison failure.
The value from customFields is stored under a dynamic key (custom field ID):
"customFields": {
"69a18668c0386b0f42a6cbb5": "69a1866ec0386b0f42a6cbb6"
}So I suspect Automation may be treating this value differently (e.g., JSON node vs string), even though the output appears the same.
Has anyone encountered this behavior when comparing values retrieved from:
a regular object property (id)
a map/dynamic key (customFields.<customFieldId>)
in Jira Automation smart values?
If so, what is the best way to normalize or reliably compare these values?
Any guidance would be greatly appreciated, as this comparison is a critical step in my automation workflow.
Thanks in advance!
Hi @Ramya R -- Welcome to the Atlassian Community!
Without seeing your entire rule and audit log for context...
Please note we have no idea what the audit log renderer does; that behavior is undocumented. Thus, the log entry adder could be performing various text formatting and type conversions to display plain text in the log viewer, and so the may values appear the same even when they are not.
Some techniques I use in a scenario like this are:
varMyValue: >>{{varMyValue}}<< has a length of: >>{{varMyValue.length()}}<<
With that logging in place, test again to observe any value differences.
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.