Custom Fields Overview
| 
PDF |
Custom field types were introduced in JIRA 2.0 to allow greater customisability of the types of data collected with your issue.
In 3.0, the number types have been expanded and you can even add your own custom field types. JIRA 3.2 adds a new level of
flexibility to your custom fields. You can now configure your custom fields to only appear for certain issue types in certain
projects or multiple issue types over multiple projects. On top of that, you can even configure each custom field differently for each
context.
This page outlines some of the key concepts relating to custom fields.
To build your own custom field types, check out the
tutorial at the
JIRA Development Hub.
Note
Custom fields are always optional fields. This means you can add custom fields without requiring
existing issues to be changed. The current issues contain no value for the custom field, even if a default is
defined.
Custom Field Types
JIRA now ships with over 20 custom field types and you can find more custom field types and other examples in the
JIRA Extensions space (e.g.
JIRA Toolkit). A sample of the types are listed below.
| Custom Field Type |
Description |
| Cascading Select |
Multiple select lists where the options for the second select list dynamically updates based on the value of the first |
| Date Picker |
Input field allowing input with a date picker and enforcing valid dates |
| Date Time |
A custom field that stores dates with a time component. |
| Free Text Field (unlimited text) |
Multiple line text-area enabling entry of longer text strings |
| Multi Checkboxes |
Checkboxes allowing multiple values to be selected |
| Multi Select |
Select list permitting multiple values to be selected |
| Number Field |
Input field storing and validating numeric (floating point) values |
| Project Picker |
Select list displaying the projects viewable by the user in the system |
| Radio Buttons |
Radio buttons ensuring only one value can be selected |
| Select List |
Single select list with a configurable list of options |
| Text Field |
Basic single line input field to allow simple text input of less than 255 characters |
| URL Field |
Input field that validates a valid URL |
| User Picker |
Choose a user from the user base via a popup picker window. |
| Multi User Picker |
Choose one or more users from the user base via a popup picker window. |
| Group Picker |
Choose a user group using a popup picker window. |
| Multi Group Picker |
Choose one or more user groups using a popup picker window. |
| Single Version Picker |
Choose a single version from available versions in the project. |
| Version Picker |
Choose one or more versions from available versions in the project. |
Search templates
Search templates are responsible for indexing a custom field as well as making it searchable through the Issue Navigator (note that custom fields are not searchable via QuickSearch).
Each of the default custom field types has a related pre-configured search template.
Custom field context
The custom field context (introduced in JIRA 3.2) allows your custom field to be configured (that is, enabled) for any numerous different combinations of issue types and projects. You can have different default values in different projects, different options for different projects and the like.
The context is made up of an issue type component and a project component. You can select multiple issue types and multiple projects or declare the custom field to be global.
The context itself can now be modified at any time. You can change the project or issue type applicable for the custom field at any time.
Custom field configuration schemes
If you start digging deeper into custom fields (or indeed, any part of JIRA) you'll notice many references to schemes. Custom field configuration schemes are how JIRA allow you to manage custom field contexts and configuration. A configuration scheme is configuration set for a group of issue types for a set of projects. If you have two different default values, you'd need two configuration schemes and so on.
Specific project based configuration schemes will override configurations from a Global project context. So you could configure a
default global scheme for all projects and the configure for each projects that are different. You may for example, have a global select lists that have values that applies for 80 of your 81 projects but is different in the other. You'd configure a one configuration scheme for global context and other for the specific field that is different.
Also note that to avoid conflicts, a project can only be part of a single configuration scheme. Once you've selected a specific project to be part of a scheme, it will be removed from the list of selectable options
