Jira 7.12 introduced the Custom Field Optimizer for Jira Data Center which has brought Custom Field Contexts to the forefront. Unfortunately, Atlassian's documentation is not clear on the impact of restricting custom field contexts from Global to Project or Issue Type based. This article seeks to clarify why this is important.
Custom Fields Optimizer is a feature in Jira 7.12 (Data Center) that scans all custom fields and allows you to automatically improve the configuration of them.
Here is an example scan for fields to optimize:
Note that the Custom Fields Optimizer has detected that these fields are not used by any projects. Looking at the fields more closely, they have been placed on screens and attached to projects, but these projects have no issues in them and thus the fields have no real use.
The Custom Field Optimizer makes it easy for Jira administrators to configure new custom fields. By default, these custom fields are available for use by all projects in the system: this is called a "Global Context". As the number of custom fields with global contexts grow, every issue in the system must load that custom field on every view or update - even if the field is not relevant to the project, has not been added to the project screen, used in its workflow, or used in some other way related to a plugin or automation.
Large numbers of custom fields with global contexts have a significant impact on system performance. Not only do they contribute to poor project performance, but can cause dashboards, issue search filters and Kanban boards to be slow.
Evaluating the impact of an excessive number of custom fields with global contexts
In a recent Jira 7.13 performance test, we used the Locust load testing tool to evaluate the response time for standard actions against a Jira system in various states:
|Server specifications: Jira Software Data Center: 1 node|
Load testing results**
As seen from above, adding a large number of custom fields with global contexts had an impact despite no other data in the system.
Project or Issue Type specific context
|Screen||Can be added to all screens||Only visible on the specified project or issue type screens||No screens|
|Index||Field indexed for all issues||Field only indexed for issues in the specified project or issue type||Field is not indexed|
|Configuration||Options on all issues||Options are only kept for the specified project or issue type||Options are deleted|
|Data||Field data is kept for all issues||Field data is only kept for specified project or issue type||Field data is deleted|
Adding a project to the field context for a field requires a project re-index before the field is available for use.
In the above example, clicking the Change Context button for the Architect Approved custom field would delete the Yes/No options for this field, and these options will need to be recreated when a field configuration is recreated for this custom field.
The Custom Field Optimizer may recommend reducing the context of a field to zero projects. The effect is to delete the field configuration altogether. The impact of this is:
The Custom Field Optimizer is not a quick fix. The purpose for each field should be evaluated by identifying what screens it is on, then checking with the project leads about the status of that field.
For example, after using the Custom Field Optimizer at a client site, the tool identified a drop-down field called "UAT Plan" and recommended it reduce its field context to 0 projects. It had a Global context, but no data at present. Further investigation identified that this field was used on a Governance Tasks project which, once upon a time, was under development but never launched. This project alone was responsible for the creation of 12 custom fields that have never been reused and were just contributing to slowing down the system. Overall, in the client's instance, up to 400 custom fields were identified to be redundant with similar background stories.
New project configurations should be first configured in a non-production environment. Following user evaluation and change approval, implement the configuration in production. This should highlight unused configuration elements such as redundant custom fields from being generated that then need change approval to remove.
If a field must be created in a production environment that isn't relevant to most projects, then a better way is to create the custom field with a Project context and the list of project configured.
** The client's system has always performed unusually slow with regards to creating issues. We believe this is due to poor issue indexing performance combined with a large number of apps.