Understanding Jira Custom Field Contexts

Owned by David Sedlock
Last updated: Nov 04, 2022 by Angelica Salazar
2 min read

Jira provides so-called “custom fields” in addition to its own built-in “system fields”. Custom fields, as the name suggests, allow organizations to customize Jira issues for their own specific needs. The Jira administrator can manage the custom fields in an installation by going to Jira Administration > Issues > Custom Fields.

Each custom field has a so-called “Default Configuration Scheme”, which the Jira administrator can view by selecting the Configure option in the menu next to the listing of a custom field. The Default Configuration Scheme specifies two things that are relevant to the use of CM4J:

  • default value - This is the value (if any) that the custom field has when an issue is first created.

  • options - These are the possible values the custom field may have if it is of a type that has a defined list of values.

The Default Configuration Scheme of a custom field is, as the name suggests, the configuration that is used by default when issues are created and modified.

However, a custom field may have additional “contexts” that are specific to individual projects. The configurations of these contexts override the default values and options of the Default Configuration Scheme for issues in the projects. For example, a custom field may have the default options “Yes” and “No”, while a specific project may override that with a context that specifies the values “Yes”, “No” and “N/A”. A context may be specific to a particular project or may be shared among several projects.

The configuration of project-specific contexts normally requires global Jira administration permission. This means that if a project wants to create such a context, or to modify an existing context, it has to turn to a Jira administrator, which introduces delay and creates a burden for both the Jira administrator and the project administrator. A better solution is to enable the project administrators to create and maintain the project-specific contexts independently of the Jira administrator - which is precisely the functionality that CM4J provides.