Scriptrunner validator letting transition happen even though return is false

[Pierre Ibrahim]

Hello!

I'm writing a scriptrunner validator on create that checks the values of certain fields and lets the ticket be created accordingly.

Script below:

issue.customfield_14690.value == "No" ? true :
issue.customfield_14690.value == "Yes" && issue.customfield_14613 ? true :
issue.customfield_14690.value == "Yes" && (issue.customfield_14440 || issue.customfield_14611) ? true :
false

When I test this in scriptrunner directly with a ticket that has cf_14690 as Yes, and with cf_14613, cf_14440, and cf_14611 as null, I get a false, however when I actually go to create the ticket, it creates just fine.

Why is the validator not actually stopping the create transition from happening?

Edit:

Also tried the following script variations with the same results:

(issue.customfield_14690.value == "No" || 
(issue.customfield_14690.value == "Yes" && issue.customfield_14613 != null) ||
(issue.customfield_14690.value == "Yes" && (issue.customfield_14440 != null || issue.customfield_14611 != null)))

if (issue?.customfield_14690?.value == "No") {
    true
} else {
    if (issue?.customfield_14690?.value == "Yes" && issue?.customfield_14613 != null){
        true
    }
    else {
        if(issue?.customfield_14690?.value == "Yes" && (issue.customfield_14440 != null || issue.customfield_14611 != null)){
            true
        }
        else {
            false
        }
    }
}

Thanks!

[Alexander Nilsson]

Hello Pierre,

the issue is how you're reading the field values inside a Simple Scripted Validator on a create transition. The issue binding at create time does not yet reflect what the user is typing into the create screen, so issue.customfield_14690.value is reading from an issue that essentially does not exist yet. The script either evaluates against null fields and silently throws, or hits a branch that returns truthy, and the transition goes through.

The binding that exposes the values currently entered on the transition screen is cfValues, keyed by field name (not by id). That is what the ScriptRunner docs use for this exact pattern, including an example that is structurally identical to yours: a Yes/No select that conditionally requires another field.

Rewritten against your three fields (replace the names with the actual display names of customfield_14690, customfield_14613, customfield_14440, and customfield_14611 in your instance):

cfValues['Your Yes/No Field']?.value == 'No' ||
(cfValues['Your Yes/No Field']?.value == 'Yes' &&
    (cfValues['Field 14613'] ||
     cfValues['Field 14440'] ||
     cfValues['Field 14611']))

Two things to double-check on the transition itself:

• All four fields must be on the screen associated with the create transition. cfValues only sees fields that are actually on the transition screen.
• The field name passed to cfValues must match the custom field's display name exactly, including case.

The full reference, including the Yes/No conditional-required-field example I based the rewrite on:

https://docs.adaptavist.com/sr4js/latest/features/workflows/validators/simple-scripted-validators

One side note on why your test in the ScriptRunner console returned false correctly but the create still succeeded: the console runs against a persisted issue you pass in, where issue.customfield_XXXXX works fine because the values are already on the database row. During a create transition there is no persisted row yet, which is exactly the gap cfValues is designed to bridge.

I am looking to your feedback.

Greetings,

Alex