nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Scriptrunner Cascading list options not hiding

Matt Grayford

Hey All,

So, I wrote this code a bit back and it was working perfectly till something happened recently. I'm not able to pinpoint exactly when it happened or anything around where it started, but I have a Cascading Select List called Category. I have a few forms on service desk that use specific options from category and hide the rest (so not as to over encumber the user.)
Recently something happened that all of them are now showing all options. I've opened a ticket with Adaptavist about it, but figured I'd see if anyone had any issues like this.

Additionally, I have nearly identical code running internally that is hiding field options on the Jira Software Create ticket button for the same project. This code is working flawlessly, but when transferring it over to Service desk, same thing, fields show.

This isn't limited to one project either, it's any project working with cascade fields. and in both my stage and my prod environments

Software is version 9.12.8, Service management is 5.12.8

Has anyone had something like this happen? Anything I should look for in particular?

Thanks in advance!

Here is the code for reference in the initializer:

import com.onresolve.jira.groovy.user.FieldBehaviours
import com.onresolve.jira.groovy.user.FormField
import com.atlassian.jira.component.ComponentAccessor
//import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.customfields.manager.OptionsManager
import com.atlassian.jira.issue.fields.config.FieldConfigImpl

import groovy.transform.BaseScript

@BaseScript FieldBehaviours fieldBehaviours

def allowedOptions = null
def optionsManager = ComponentAccessor.getOptionsManager()
def customFieldManager = ComponentAccessor.getCustomFieldManager()
def Category = getFieldByName("Category")
def CategoryCustomField = customFieldManager.getCustomFieldObjectByName("Category")
def c_fieldConfig = CategoryCustomField.getRelevantConfig(issueContext)
def c_customField = customFieldManager.getCustomFieldObjectByName("Category")
def c_config = c_customField.getRelevantConfig(getIssueContext())
def c_options = optionsManager.getOptions(c_config)


//Category
// Set the values inside the select list field for Request Category
def CategoryMap = [null: "None"]

     CategoryMap += c_options.findAll { it.value in ["New Access Request","Microsoft Office Suite","Virtual Desktop"]}
     .collectEntries { [(it.optionId.toString()): it.value]}
     Category.setFieldOptions(CategoryMap)
//getFieldByName('Type').setHidden(true)

Accepted answers

Matt Grayford

Just a quick update for everyone, Adaptavist now has a ticket for this. https://assist.adaptavist.com/browse/SRJIRA-7535 Please go there and upvote/watch it for a resolution. Thanks

Matt G

All comments

Ram Kumar Aravindakshan _Adaptavist_

Hi @Matt Grayford

Please clarify what version of ScriptRunner you are currently using.

Also, it would be helpful if you could also share a screenshot of your Behaviour configuration so I can review it and try to test it in my environment to see if it requires further modification or correction.

I am looking forward to your feedback.

Thank you and Kind regards,

Ram

Matt Grayford

Hey Ram, Thanks for the response.

Version is 8.34.0

No major changes in the config settings for it. Simply just the initializer code. There is one field getting changes made in it based on this initial code. (field name is Type.) That code is within the Category field option section and has no impact on the category field itself. Simply reads the category field and sets the appropriate options for Type. (which is basically the same code, just a select list and not a cascading select list.

The same is true for the other projects doing the same thing.

Setup is simple. Setup a JSM project, put a cascading field on the project. Map to that project and form in behaviors. Try to limit your options using the code I provided and change the values to match what you have. Save and take a look. If it works for you, then something else in my environment is off, and I'll have to look from there

Thanks

Matt

Padma Kothakot

Hi @Ram Kumar Aravindakshan _Adaptavist_ ,

We are facing the same issue where the cascading list is not prepopulating after upgrading jira. Our current Jira software version in 9.12.11 and Jira Service Management 5.12.11. Could you please suggest us how to fix this issue

Thanks,
Padma

Ram Kumar Aravindakshan _Adaptavist_

Hi @Matt Grayford

I am not able to replicate this issue in my environment.

Using the approach that you have mentioned, I am still able to get the Cascade Select List to filter on load time via the Initialiser.

Below is the sample working code that I have used:-

import com.atlassian.jira.component.ComponentAccessor
import com.onresolve.jira.groovy.user.FieldBehaviours
import groovy.transform.BaseScript

@BaseScript FieldBehaviours behaviours
def sampleCascade = getFieldByName('Sample Cascade')

def optionsManager = ComponentAccessor.optionsManager

def filteredCascadeField = customFieldManager.getCustomFieldObject(sampleCascade.fieldId)
def availableConfig = filteredCascadeField.getRelevantConfig(issueContext)
def listCascadeOptions = optionsManager.getOptions(availableConfig)

def availableOptions = [null: 'None']

availableOptions += listCascadeOptions.findAll {it.value in ['Parent1', 'Parent3'] }.collectEntries {[(it.optionId.toString()) : it.value.toString()] }
sampleCascade.setFieldOptions(availableOptions)

Please note that the sample working code above is not 100% exact to your environment. Hence, you must make the required modifications.

Below is a screenshot of the Behaviour configuration:-

If you notice the code I have tested with, it's similar to your approach.

The original parent options for the cascade select list are Parent1, Parent2, and Parent3 as shown in the screenshot below:-

The code I tested excludes Parent2 and only displays Parent1 and Parent3 with the child list options accordingly.

Below is a screenshot of the Cascade Select List from the JSM view. As you can see, only parent options, Parent 1 and Parent 3, are available.

Accordingly, the child options are also available as shown in the screenshots below:-

If your approach matches this but is still not able to work as expected, I suggest trying to temporarily disable all your other Behaviour configurations to ensure that there is no conflict between the configurations.

I hope this helps solve your question. :-)

Thank you and Kind regards,
Ram

Matt Grayford

Thanks for testing that Ram, I'm not able to reply on that comment for some reason but I'll reply here at least.
So I tried your code out and had the same results.

Options showing.png

The only things I changed was the Sample code Field name and the values for a couple options. I'm still seeing all options available under the parent.

I also, commented out the second value (type) in the follow-up section to make sure nothing was overlapping, and the problem still persists. I think the main point of concern for me is that this isn't limited to one project. It Does seem to be limited to Cascading fields though. As the same code works on Single select and multi select lists. This leads me to believe something is going on with cascade options in general. I may raise a ticket with Atlassian, if Appfire themselves can't identify it. (which their latest test suggests they can't, as they repeated your steps pretty much exactly and it worked for them.)

Thanks,
Matt

Matt Grayford

Just a quick update for everyone, Adaptavist now has a ticket for this. https://assist.adaptavist.com/browse/SRJIRA-7535 Please go there and upvote/watch it for a resolution. Thanks

Matt G

Zydek, Rafal

Is it a workaround that can be used to handled the problem before bugfix?

Ram Kumar Aravindakshan _Adaptavist_

Hi @Zydek, Rafal

At the moment, there is no work around for the Bug.

You will have to wait for the fix to be released.

Thank you and Kind regards,
Ram

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

data-center

jira-service-management

jira-service-management-data-center