Our customer is exploring an extensive use of project specific select field.
As a best practice, it helps in the performance to set a project context instead of having a global context.
However, an interesting question pops up if we stretch the limit in the other direction.
What if we add a new context for every project in the Jira instance? Will it scale gracefully?
I did not manage to find any documented limits on the maximum number of context for a given custom field.
Will be thankful if anyone has any insight.
>As a best practice, it helps in the performance to set a project context instead of having a global context.
Actually, that's a lot less true now. Since version 8 when the index system was updated to a much better version, and, more importantly here, stopped indexing empty fields in full, the contexts have much less effect on performance than they used to.
>What if we add a new context for every project in the Jira instance? Will it scale gracefully?
It'll scale, there's no maximum limit, but I would not call it graceful - each different context is a different thing to have to process. If possible, stick with a global context!
Thanks for your advice :D
It seemed that Atlassian is still recommending to limit the number of global custom fields as of Jira 8.14.
Custom fields can have two contexts—global and project-specific. The global context used to be the default choice, but such custom fields are applied to all issues in your instance and can affect performance. We’ve made a few simple improvements that will help you choose the right context.
Now, you can select the custom fields' context as you create them. Hopefully, your fellow Jira admin will think twice when choosing one. This should help you limit the number of global custom fields and keep your Jira instance in the best shape possible.
I also tested previously with REST API call to get the issue values. For those fields with global context, the fields will be included in the JSON with null values. Hence I suspect there is still an overheads in loading an issue with a lot of global fields.
Another reason for individual project context is we want to allow each project to manage their own options (similar to component/s and version/s).
My gut feel is when a field is rendered on a create screen, it will pass the project and issue type to search for a matching context. If there is no matching context, then it will use the global context.
The performance will not scale if it loads all the contexts and check for a matching context sequentially.
Perhaps the way to validate is to add a lot of context to 1 field and see how the performance scales.
Hello Community! I hope you've been enjoying the 🍂Apptoberfestivities🍂 (I know I have!) The event is heating up next week with a series of virtual events that we're calling the 🍻🍂Partner App ...
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