Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to avoid the loading of options on a customfield list ?


To give you the context, I have a first custom field with around 500 values that works well and second multiselect list with around 10000 values. 

The displayed options of the second list depend of the value set on the first list (I used a json file to do this). 

// Récupérer les applications :
File file = new File("")
def fileText = file.getText()
def list = new JsonSlurper().parseText(fileText)

def result = list['Projets'].find {
it['LibelleProjet'] == tabG2 }['Activites'].collect { it['CodeActivite'] + '_' + it['libelleActivite'] }

def optionsMap = options.findAll {
it.value in result // list of options you want to show
}.collectEntries {
(it.optionId.toString()): it.value

 So that works too.

The problem is that the 10000 values are always loaded in background and it causes slowness...

Is it possible to avoid that forms load the 10000 values ?

I tried to do that on an intialiser but it's always slow, the options are always loaded in backgound

def result

def optionsMap = options.findAll {
it.value in result // list of options you want to show
}.collectEntries {
(it.optionId.toString()): it.value

If you have suggestions for an alternative, do not hesitate to answer :) 

1 answer

0 votes


Wow, 500/1000 values in a select!

That must be a pain to manage.

Considering that behaviour only impacts the DOM in the browser via javascript, the setFieldObptions can only hide the elements you don't want to show. There is no way to prevent jira to load those values.

I think you might have better performance given your use case if you use 2 plain text fields and convert them using the behaviour convertToSingleSelect method.

This would require you to create a rest endpoint to serve data from your JSON.
But the advantage here is that you only serve the result that matches the user's type-ahead query and the value selected in the first field.

The other advantage is that now you only have a single place to manage the list of values. I am guessing that right now, to add a new value, you must add it both to the custom field configuration and in the JSON file.

Also, you can start to consider putting the data elsewhere than in a JSON file. Perhaps another database you might have access to.

Thanks for you reply!

Unfortunately this is the solution we are currently using but it is causing us problems that we are no able to solve.

With the same mecanism, the option displayed on the second list depent of the value on the first one and when we try to set values on the second, we have an error ...


After long investigations we didn't find what was the problem and it's why we tried the second option to directly load the value on "classic" fields.

For information, I use my json to add value in my two fields with the help of a script. 

So with this solution, I also have a single place to manage my lists. 

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events