Behaviours - Trouble with visibility of fields base on selection of a dropdown field

[Melanie Pasztor]

Hello!

I am trying to implement a script that adjusts the visibility of a few fields base on the selection of another single select dropdown field. Tried different methods found online and from the atlassian community responses to other similar questions, but fields do not hide from the start, and cannot tell if rest of code works without that. At least attach code to a field.  Initializer works for hiding the fields, but not conditional stuff like re-appearing them with a selection.

What I have presently:

def impactField = getFieldById("customfield_15890")
def severityField = getFieldById(getFieldChanged())

def selectedOption = severityField.getValue() as String
def isImprovementSelected = selectedOption == "Improvement"

impactField.setHidden(! isImprovementSelected)
impactField.setRequired(isImprovementSelected)

I've tried basing on this https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html#undefined which does work, but this method does not work with customfields it seems. 

Most I can guess as causes is forgetting a syntax, or import declaration, or something to do with custom fields. Suggestions? Ideas? Example somewhere using customfields instead?

Thank you!

Melanie

[PD Sheehan · Accepted solution]

I'm assuming you have this code in the Severity field since you're getting the field with getFieldChanged(). If you don't, then that's the root of your issue. You need the server-side script ON the field that you want to respond to user action. If you have multiple fields that could trigger your action, you need a server-side script on each of those fields.

I'm also assuming that your severity field is a single select and one of the options will have "Improvement" as its value.

So my thinking is that maybe  "severityField.getValue() as String" is not returning what you are expecting.

There are 2 ways you get debug that. You can throw some statements in the log and monitor that. But sometimes, I like to use the setHelpText() for debugging.

For example:

def impactField = getFieldById("customfield_15890")
def severityField = getFieldById(getFieldChanged())

def selectedOption = severityField.getValue() as String
def isImprovementSelected = selectedOption == "Improvement"

severityField.setHelpText("selectedOption=$selectedOption isImprovementSelected=$isImprovementSelected")

impactField.setHidden(! isImprovementSelected)
impactField.setRequired(isImprovementSelected)

This will show you in real-time and on-screen what your script is detecting.

[Melanie Pasztor]

Yes, I have it as a server side script on a custom single-select field called Severity, with the only field and only one option that triggers the rest of the script. I can attempt more complexity afterwards once I figure this basic one. 

Thank you for the debug suggestion! 

[Melanie Pasztor]

Well, it is a reminder to check the logs more often as setHelpText did not work either, suggesting the entire script is not being runned at all. 

I checked the jira logs and it is spitting this out: 

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script1.groovy: 14: you tried to assign a value to the class 'com.onresolve.jira.groovy.user.FormField'
@ line 14, column 1.
FormField = getFieldById(fieldChanged)
^

Something is breaking groovy somewhere on this test instance, and none of my scripts I can see they are either not that long or line 14 is blank. :P 

[PD Sheehan]

That is something that often bugs me ... in such errors, it's impossible to know which of your in-line script is causes the error.

The only way around that would be to have 100% of your script in individual files.

The next thing to do it to use the script registry built-in script, switch to the behaviours tab and look at every line 14 to find the culprit.

[Melanie Pasztor]

Found the offensive script that caused the error. It was another behaviour script that happened be trying to do something else with the same custom field without defining variables. 

It means my own script does actually work, once it has a chance to run. Woot!