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?
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.
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?
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.
Thanks for this post ... Is there any progress or update in terms of how Atlassian is approaching this topic for Cloud instances? I.e. we also have a field or 2 that have +5K options and it is populated via the REST API ... But not sure how to handle the performance degradation on the UI side as a result of the number of fields.
We had this requirement where we needed to load more than 15k options and allow it to grow 2 to 3 times. We first tried with a multiselect custom field adding a JS in the description to allow search but it did not work, was taking 2-3 mins just to load the page. We also tried select2 add-on but that also had similar issue as it also requires all options to be loaded on the client side.
We solved this issue with this approach - Instead of a drop down, we created a project and a new issue type and added all 14k options as new issues in that project. Now we are using a multi issue picker field provided by ScriptRunner add-on and it works like a charm as it has aut-suggest feature and it can scale easily to as many issues as your JIRA project has.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events