Custom Field Types

A custom field type defines the format of the values allowed for a field.

All supported types can be divided into two categories:

Simple types — these types include date, integer and string types.
Enumerated types — these types let you select a value from a predefined list.

YouTrack supports the following custom field types:

Simple Types

Field Type	Description
`float`	Stores a single value as a floating-point number.
`date`	Stores a value in date format.
`period`	Stores a value that represents a period of time. By default, fields of the this type are used for time tracking.
`integer`	Stores a single value as an integer.
`string`	Stores a single value as a string of characters.

Enumerated Types

Field Type	Description
`build[1]`	Stores a build number from a predefined set of build numbers. Fields that use this type also store the `assembleDate` when the selected build was assembled as a property with a date data type.
`enum[*]`	Stores one or more values from a predefined set of values.
`enum[1]`	Stores a single value from a predefined set of values.
`user[1\|*]`	Stores one or more values (user names) from a predefined list of user accounts. The most obvious example is the Assignee field.
`group[1]`	Stores a single value (group name) from a predefined list of user groups.
`group[*]`	Stores one or more user group names from a predefined list of user groups.
`ownedField[1\|*]`	Stores one or more values from a predefined list. When you use this type, you define an owner for each value in the list. The owner is a user account that is responsible for the value. For example, the Subsystem field.
`state[1]`	Stores the state of an issue from a predefined set of issue states. Fields that use this type also store an additional `isResolved` property as a Boolean value. This property indicates whether the issue is considered to be resolved when it is assigned the corresponding value in this field. For more information on state-type fields, see Possible Conflicts with Multiple State-type Fields.
`version[1]`	Stores a single value (version) from a predefined list of versions. Fields that use this type also store the `releaseDate` when the selected version was released as a property with a date data type. Each version can also be assigned a `released` property that indicates whether the version is released and an `archived` property that indicates whether the version is archived.
`version[*]`	Stores one or more versions from a predefined list of versions.

Possible Conflicts with Multiple State-type Fields

If you add more than one custom field that uses a state type to your project, you can create some undesired results. Your issues are not resolved until all state-type fields are assigned values that are considered to be resolved. Unless your users are informed about this requirement, confusion arises. They will change the value of one state field to resolve an issue, but the visual presentation of the issue remains unchanged — not dimmed with a line through the ID as is expected for resolved issues.

For this reason, we strongly advise against using more that one state field in a project.

If you weren't lucky enough to have read this warning before you created issues in your projects, there's still hope. The following solutions can help you get the functionality you want without annoying your team.

The easiest workaround is to mark all of the values for all extra state-type fields as resolved. Your users only have to manage the values in a single custom field to determine whether the issue is resolved or not.
The preferred solution is to replace extra state-type fields with fields that use a generic enumerated type. This makes the resolved state dependent on the values for a single custom field.
Unfortunately, you can only use the Replace function with custom fields that share the same data type. Use the following procedure to create new enumerated custom fields and remove extra state-type fields from your projects.

To replace extra state-type fields:

Open the Administration > Custom Fields page.
Locate the project that contains extra state-type custom fields.
Click the Add field to project button.
Use the settings to define a custom field that stores an enum type.
Add the same values to the new custom field that are used in one of the extra state-type custom fields.
When finished, update the values that are stored in the custom fields for your project:
- From the issues list, enter a search query that finds all of the issues that contain a specific value in the state-type custom field. Start with the first value in the set. For example: In #{Project} Status: Submitted.
- Select all of the issues that are returned by the search query. Use the keyboard shortcut Ctrl + A (⌘ + A on OS X) to select all of the issues that are returned by the query.
- Use a command to update all of the selected issues and assign them the same value in the new enumerated custom field. For example: Secondary State Submitted. To minimize notification spam, apply the commands silently.
- Repeat this step until you have added all of the values that were stored in the state-type custom field to the new enumerated custom field.
Return to the Administration > Custom Fields page and remove the extra state-type custom field from the project.
- The field and its related values are deleted from the project.
- All of the values that were previously stored in this custom field are now stored in the enumerated custom field.
Repeat this procedure until you have replace all of the extra state-type fields in the project.

Last modified: 2 February 2017