Behaviour scriptrunner set form value for select( single choice)

[Alex]

Hello Atlassian community! I really need your help. I'm trying to set the value of a field depending on the selection in another field. I use "Behavior"  but none of the options found on the Internet solved my problem.

I have two fields: "CPU" and "RAM". My task: depending on the choice in cpu, automatically substitute the value in ram. Values:

CPU: 2 -> RAM: 2, 4, 8, 16 (Displayed list of ram options)
CPU: 4 -> RAM:  4, 8, 16, 32
CPU: 8 -> RAM:  8, 16, 32
CPU: 32 -> RAM:  32

[Stefan Salzl · Accepted solution]

Hi @Alex 

i found a post that seems similar to your problem:

https://community.atlassian.com/t5/App-Central-questions/hide-options-from-select-list-field-values-based-on-Request-type/qaq-p/2078725

As far as I got that right all possible options need to be configured in the field (RAM). Then depending on the option selected in the CPU field the behaviour  hanges the options within your RAM field.

Therefore the behaviour script need to be configured for the CPU field as this is the „trigger“ (underlying) field. Whenever this field changes it will trigger the script.

Hope I could give some helpful input. Please let us know in case you get stuck or have any further questions.

Best
Stefan

[Alex]

@Stefan Salzl Hi! I can’t seem to adapt it to my task :(

[Stefan Salzl]

@Alex 

Could you explain why? What‘s the difference? did I get you requirement wrong?

Best
Stefan

[Alex]

@Stefan Salzl I can’t figure out the code; for some reason the issue type is in the condition. Unfortunately, I don’t know how to change this for my situation

[Alex]

I'm sorry, I'm not very good at script runner

[Stefan Salzl]

Hi @Alex 

I tested the following snippet in my environment and it does the expexted work for the first CPU-option of 2. You can use this as a template for the other options and create them as else blocks (I created CPU and RAM select fields so you just have to change the customfield_IDs according to your fields):

import com.atlassian.jira.component.ComponentAccessor

def cfManager = ComponentAccessor.getCustomFieldManager()

def optionsManager = ComponentAccessor.getOptionsManager()

def ramCF = cfManager.getCustomFieldObject(29201)

def ram = getFieldById("customfield_29201")

log.warn(ram)

def cpuHide = getFieldById("customfield_29200")

log.warn(cpuHide.getValue().toString())

def ramConfig = ramCF.getRelevantConfig(getIssueContext())

def options = optionsManager.getOptions(ramConfig)

if(cpuHide.getValue() == '2'){

    ram.setHidden(false)

    def optionsMap = options.findAll {

        it.value in ["2","4","8","16"] 

        }.collectEntries {

            // [ (it.optionId.toString()),it.value.toString()]

            [ it.optionId.toString(), it.value]

        // log.warn("optionID: " + it.optionId)

        // log.warn("value: " + it.value)

        }

        log.warn(optionsMap)

        ram.setFieldOptions(optionsMap)

    }

else{

    // ram.setHidden(true)

}

Hope this helps.

Best
Stefan

[Alex]

@Stefan Salzl 

Hello! The script only works on the editing screen. When creating a task, the values ​​do not switch depending on the CPU fields.

[Alex]

@Stefan Salzl 

Is it possible to do the same thing but on the creation screen? Thank you

[Stefan Salzl]

@Alex 

Could you please show a screenshot of the configuration of you behaviour (the general behaviour settings - mapping, workflow,... - as well as the fields settings)?

It also works on create screen in my system and it in general as far as the behaviour itself doesn´t have any limititation configured it should behave like this in the create screen too (as the script itself doesn´t do any limitatioin, it just knows: "for this field I need to do that behaviour").

best
Stefan

[Alex]

@Stefan Salzl  Hi! Yes, sure ! 

my screen behaviour :

log error :

2023-10-20 21:32:42,837 ERROR [behaviours.BehaviourManagerImpl]: *************************************************************************************
2023-10-20 21:32:42,839 ERROR [behaviours.BehaviourManagerImpl]: Script function failed on issue: issue: TEST-191, user: adm_avrd, fieldId: __init__, file: <inline script>, edit behaviour:
java.lang.NullPointerException: Cannot invoke method getRelevantConfig() on null object
at 32780520cdb50911e52d4303d495f40e.run(32780520cdb50911e52d4303d495f40e.groovy:9)

It's strange that everything works fine on the editing screen

but for some reason the script didn’t work on the creation screen

 

[Alex]

@Stefan Salzl 
 In the code, only the line is highlighted:

ram.setFieldOptions(optionsMap)

[Peter-Dave Sheehan]

The clue is here in the error:

Cannot invoke method getRelevantConfig() on null object
at 32780520cdb50911e52d4303d495f40e.run(32780520cdb50911e52d4303d495f40e.groovy:9

The very last bit ...groovy:9 means that your error is on line 9 of the code. Which is not diplsplayes in any of the screenshots.

But I suspect that maybe it has something like

.getRelevantConfig(underlyingIssue)

instead of

.getRelevantConfig(issueContext)

The underlyingIssue is empty on a create screen, while the issueContext is always valid (and includes the project and issue type which can be used to identify the proper context from your custom field configuration).

[Stefan Salzl]

@Peter-Dave Sheehan 

Awesome analyse. Thanks for that valuable input. I could again learn a lot from this post.

Thanks.

Best
Stefan

[Alex]

@Peter-Dave Sheehan 

Hi! Thank you, I corrected this line that you highlighted and everything remained the same, but now the error looks like this

2023-10-21 08:26:19,282 WARN [runner.ScriptBindingsManager]: Form field ID: customfield_23843, value: -1
2023-10-21 08:26:19,305 WARN [runner.ScriptBindingsManager]: null
2023-10-21 08:26:19,309 ERROR [behaviours.BehaviourManagerImpl]: *************************************************************************************
2023-10-21 08:26:19,333 ERROR [behaviours.BehaviourManagerImpl]: Script function failed on issue: (create issue) project/issuetype: TEST/Epic, user: adm_a, fieldId: __init__, file: <inline script>, edit behaviour: 
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method com.atlassian.jira.issue.fields.ImmutableCustomField#getRelevantConfig.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[interface com.atlassian.jira.issue.Issue]
[interface com.atlassian.jira.issue.context.IssueContext]
[interface com.atlassian.jira.issue.context.JiraContextNode]
at 1a8e57d21d9bf03a9d873f95360041db.run(1a8e57d21d9bf03a9d873f95360041db.groovy:17)

[Peter-Dave Sheehan]

The same comment applies, you should not use "underlyingIssue" if you expect a script to work for both issue creation as well as issue edit.

[Alex]

@Peter-Dave Sheehan 

ah, I'm sorry, I didn't read your answer carefully. I'll fix it now

[Alex]

@Peter-Dave Sheehan  I changed it to the line of code that you attached in the comment above, and everything remained unchanged.

This is my first time working with “behavior”, and maybe I haven’t configured something yet, for example, maybe I need to add a field in the “Add Field” line? Don't know ..

[Alex]

@Stefan Salzl  @Peter-Dave Sheehan Now my code is in the "Initialiser" window.

this is right ?

[Peter-Dave Sheehan]

Can you share your full script?

Your code will need to be associated with the CPU field, not the initialiser.

So add the CPU field, then click on add server-side script, and put the script in there.

[Alex]

@Peter-Dave Sheehan 

You were right ! I lacked context! I added the code for the "CPU" field to the server-side script window and it worked! Thank you very much for your help!

[Alex]

@Stefan Salzl Thank you very much for the code! It turned out to be completely working for me. At first, out of inexperience, I didn’t add the context, but  @Peter-Dave Sheehan helped me with his experience, and now everything works perfectly! Thank you very much for your help! I am very grateful to you!