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; } } }

Cascading Select Field Loads Really Slow due to many entries

Srikanth Ganipisetty_3xgf81

Hello,

We need your help with a workaround solution for the Cascading Select fields, especially when they have too many entries and need to perform CRUD operations.

The Edit page is loading very slow, in fact, it's using the browser's RAM and shutting down. I was able to write some programmatical code for to Create, Delete, Enable and, Disable methods. But didn't find any docs/community support pages to give us a clue on updates (like renaming these options). Etc.

Please suggest a workaround solution and best practices follow moving forward.

Thanks,
Srikanth Ganipisetty

Accepted answers

Nic Brough -Adaptavist-

There is nothing you can do with this, other than re-work your data into a sensible usable shape.

The problem is this long select list is breaking your page load. Behaviours can't help you - they run after the page has been loaded.

You shouldn't be using a select list that has more than a couple of hundred options, it doesn't work for the humans and it doesn't work in the browser.

Your only option is to question why you've got far too many useless options in your list and work out a different way to do it.

All comments

John Funk

Hi @Srikanth Ganipisetty

How many values to you have in the top level select? And is there anyway to group those values into smaller subset? So, I guess I should ask what type of data is in the top select?

Another option might be to use ProForma forms to put in some conditional logic for the values.

Srikanth Ganipisetty_3xgf81

Hi @John Funk

We have this Single List Cascading field as

"Field Name" -

2 Parent Options -

Parent Option1 - 6400 Entries, (Single Custom Field Context)

Parent Option 2 - 1600 Entries. (Single Custom Field Context)

It makes sense of why the page is loading really slow and sometimes it never loads. Yes, I worked on a scenarios to subset them... but I faced an issue, when I tried using custom field contexts to split these 6400 entries into 6399 into custom field context1, 1 entry into custom field context2. All I see in the dropdowns is only one entry and the rest 6399 entries in the other context are hidden. Is there a formula/template you can suggest to subset them into? The other scenarios I am thinking is once if I was able to subset them, I can write some behaviors to show them in drop downs on view screen by their 1st alphabetical order. Yes, we will try ProForma, but do not know our organization would add some more dollars to purchase this plugin.

Thanks,

Srikanth Ganipisetty

John Funk

It sounds like Behaviours is your best bet to try then.

Srikanth Ganipisetty_3xgf81

Sure, but can you help on arranging the subsets of these 6K+ records with the same custom field contexts? So it will be easier to edit and display.. within the custom field configuration page.. and once these are completed sub setting, I can apply behavior on top of it.

Thanks,

Srikanth Ganipisetty

Nic Brough -Adaptavist-

There is nothing you can do with this, other than re-work your data into a sensible usable shape.

The problem is this long select list is breaking your page load. Behaviours can't help you - they run after the page has been loaded.

You shouldn't be using a select list that has more than a couple of hundred options, it doesn't work for the humans and it doesn't work in the browser.

Your only option is to question why you've got far too many useless options in your list and work out a different way to do it.

Srikanth Ganipisetty_3xgf81

Hi @Nic Brough -Adaptavist-

Thanks for the clarification and it helped. All of those options (6000+ ) are the actual products that we maintain in order to support business requirements. So our team is using this field since the beginning. What is the best way to manage these systems without using behaviors? Is there any workaround / Plugin you can recommend that handles this issue? @John Funk is recommending Pro-forma can manage some use cases like this? Can we try Pro-forma otherwise? Considering the business, we will definitely be receiving more systems onboarding into this field. ie. more than 6000+ Options.

I'm afraid that re-working our data into sensible shape like possibly changing this 6000 value into A_E Systems of 100, F-G of 100 entries each needs business approvals and the user training too. We have to start updating the pipelined scripts and applications capturing this field too.

Thanks,

Srikanth Ganipisetty

Nic Brough -Adaptavist-

There are only really two options here, although both of them are really "sort your process out" rather than "botch the software"

My suggestion is to simplify your data into a more usable shape.
@John Funk suggests using forms to do much the same "let the humans define what we put in" thing. It's a better answer than mine, and does align with "make it easier for the humans"

If you have a field with 60+ options, you have a problem with your data. No human can work accurately with that.

It's irrelevant what business approvals might need doing to get your data into a useful shape, just tell them that they're wrong (meaning "more expensive") and do it the right way. If you do it the right way, you don't need user training, you let your users do it the way they want to and all the reporting falls out naturally.

Srikanth Ganipisetty_3xgf81

Thank you so much @Nic Brough -Adaptavist- and @John Funk for your responses and confirmations. We will change the process the way we using these fields now.

Srikanth Ganipisetty

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

server

jira-software

api

jira-software-server

select-list

cascading-select