Are there limitations to number of options in custom fields?

Are their limitations to the number of options one can have in custom fields?  Hard limits or performance limits?  Are their ways to improve performance when using a custom field with a large number of options?

My situation:
I have a custom field that is a multi-select with our customer names.  The list of customers is quickly approaching 10,000 (good for the business, not good for a JIRA admin).  The page is obviously very long with that number of options.  When I need to add/remove individual customers, the Edit Options screen takes a while to load. To click any link on the page I have to mouse-over it for about 6 seconds before I can click the link/button/etc. 

Is there a better practice for a field with this many options?  There's no scripting or anything complicated about the field, it's just a list of values.  But it's a very long list and a growing list. 

 

If it would help, I could get more hardware thrown at the server, but I'd need to know if that would directly impact performance in this particular situation.  Besides this field, we have no issues with performance.

4 answers

This widget could not be displayed.

There is no hard limit but I strongly discourage this approach because of useability concerns. A list with 10K issues are not going to help the users or admins. I am surprised the users haven't complained yet!

As you already experienced, performance on page load will also take a hit because of those many options.

If you can limit the options based on project and/or issuetype, that is the best option. If not, go for a component or user picker style field where the options appear as the user types in the letters. You will have to develop the new field type (or purchase a plugin that has it) and migrate the existing field to the new type. But worth the investment given the pain you will come across later.

It is a field where users can type in a value and it auto-completes. I agree it wouldn't be useable otherwise. It's used by tech support when a customer-reported issues comes in, so they can type in the customer name. I'm not sure how I would break that up into smaller lists, the best I could do is by industry which would only get us into about 5 smaller lists, but that would leave it on tech support to know which industry-specifc field to use - and we'd have to change queries. When creating an issue, the auto-complete actually isn't too bad a second or two after you begin typing it presents matches. I'm curious if throwing additional processors or memory at the server would help, or if there's limitations in other places like web server, client side, etc. In which case I will just live with it as is. Does data type in the options matter, if I stripped special characters out of the customer names in the list would that have any impact?

Make me feel a lot better to know that it is an auto complete field ;) I do not think adding too much memory would help because the processing time is probably most spent on the client side. Maybe you can think about caching some of this data on the client side and that will probably improve performance! Don't think special characters will cause any issues unless you are seeing some javascript errors (possibly caused by parsing of results).

This widget could not be displayed.

If your problem is just how long it takes to add new options as an admin you could try a REST resource or a custom admin page. I'm impressed JIRA works with this many options. 

Or script runner and a script to add a new option

This widget could not be displayed.

Please be aware of https://jira.atlassian.com/browse/JRA-44588 , Multi Select List  and CascadingSelect fields are affected. JIRA needs to cache all values and it's doing in non-optimal way. 

This widget could not be displayed.

I created a project where each ticket is a customer(client directory). I then created another project for employees(personal directory). Each time a ticket is emailed in I parse the email address to a custom field then link that new ticket to both the ticket in the client directory and the ticket in the employee directory. If that email address is not in our crm I also parse the domain and try and link the email to at least the company. I then set the assignee of the new ticket to the assignee of the company.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

112 views 2 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you