Bug with SIL scripts and custom fields

[Addactis Support&Operations]

Hello,

We have several SIL scripts to verify some field before closing a jira ticket.

For exemple, this script below verifies that the "Entity" custom field is not set to a default value named "ND" (it's a dropdown list) :

string errorMsg = "The entity cant be " + customfield_10300;
if (customfield_10300 == "ND")
{
return false, "Entity", errorMsg;
}

But since we upgrated SIL Engine to version 5.8.0.2, these scripts dont work.

Indeed, when we select for exemple "Value A" for the field Entity, when the SIL Validator script is called, we still have the error "The entity cant be ND" telling that the field is still having the default value. It's like if the script is running before reading the new value of the field.

Can you provide us some help to fix these scripts, or correct the bug if it's one ?

[Addactis Support&Operations · Accepted solution]

Hello,

The Anova support just responds us, and it runs perfectly :

The issue you’re encountering, although represents a problem for you, is actually not a bug, but a fix for an older bug.
We needed to make a difference between the values stored in the issue and the value from the transition screen, so we made the convention that we’ll use:

• customfield_xxxxx / fieldName or - to get the value saved inside the issue
• getInput(“customfield_xxxxx”) or getInput(“fieldName”) - to get the value from the screen. (https://anovaapps.atlassian.net/wiki/spaces/PSJ/pages/1131021259/getInput )
• hasInput(“customfield_xxxxx”) or hasInput(“fieldName”) - to check if there is a value set on the screen (https://anovaapps.atlassian.net/wiki/spaces/PSJ/pages/1130726166/hasInput )

At a certain version, we haven’t discovered exactly where, a bug was introduced and the issue value wasn’t being returned anymore. We discovered it a few weeks ago and fixed it, by restoring the expecting behavior. We knew that there may be some customers who have already implemented scripts using the wrong version, but we assumed the risk of upsetting them, by knowing that the fix is really needed.

using : getInput("customfield_10300")