Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,365,563
Community Members
 
Community Events
168
Community Groups

Having a separate custom field context for each project

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.

1 answer

0 votes

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

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events