Documentation for JIRA 4.0. Documentation for other versions of JIRA is available too.
On this page:
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.
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.
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 |
説明 |
---|---|
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 |
日付と時刻 |
A custom field that stores dates with a time component. |
フリー テキスト フィールド (無制限のテキスト) |
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 ensuring only one value can be selected |
Select List |
Single select list with a configurable list of options |
テキスト フィールド |
Basic single line input field to allow simple text input of less than 255 characters |
URL フィールド |
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 |
プロジェクトで利用可能なバージョンから 1 つのバージョンを選択します。 |
Version Picker |
Choose one or more versions from available versions in the project. |
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.
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.
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