Having a separate custom field context for each project

[Hua Soon SIM _Akeles_]

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.

Thank you.

[Nic Brough -Adaptavist-]

>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!

[Hua Soon SIM _Akeles_]

Hi Nic,

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.

Set context for custom fields as you create them

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.