Update Field Values
The collection of fields that are available in each issue in YouTrack is defined at the project level. These fields store values that convey basic information and help to sort issues into a variety of categories. The basic behavior of each field is defined by the type of data that it stores. For example:
Fields that store dates or dates and times let you pick dates from a calendar.
Fields that store enumerated values let you select one or more values from a list.
Fields that store simple types like strings and integers let you enter the value directly in the field.
Project administrators can also tune the behavior of these fields. These settings can vary from project to project. As a result, you can experience a wide range of options when you set and update values for different fields in an issue. Use the information on this page to familiarize yourself with each of these options.
Supplemental Text Fields
YouTrack supports custom fields that store values as text. These fields store a string of characters that is interpreted in Markdown syntax when shown in the issue.
Fields with this type are not shown in the sidebar with other custom fields. Instead, they appear just below the issue description.
As with the issue summary and description, you can only change the values for text-based fields when an issue is open in create or edit mode. When editing these fields, a preview of the input is shown as formatted in Markdown. For a complete list of formatting options, see Markdown Syntax.
The only difference between Markdown in text fields and Markdown in the issue description and comments applies to user mentions. User mentions in text fields are replaced with the user's full name and set as a link, but don't trigger notifications as they do when added to an issue description or comment. These mentions are also excluded from the results for search queries that use the mentions attribute.
Otherwise, working with supplemental text fields is just like any other custom field in YouTrack.
To learn how to add fields to a project, see Add a Custom Field.
To learn more about fields that store vales as
text, see Simple Types.
Required Fields
A project administrator can configure a field to require a value. Required fields cannot store an empty value, but are not assigned a default value. When you report an issue in the project, required fields are shown with the message Set value in the input field.
If you attempt to create an issue without setting values for required fields, a message indicates that there are fields that require input. The inputs for required fields are briefly underlined in the fields panel.
For more information, see Required Custom Fields.
Conditional Fields
Conditional fields are shown only when a value is selected in another custom field. The most common use case is to choose which fields are shown for different issue types. However, a project administrator can add a condition to show specific fields based on the selection in any enumerated field, not just issue type.
In the following example, the visibility of the fields that store the YouTrack Version and Hub Version are based on the value that is selected in the field that stores the Product name.
If the empty value is selected, the fields that store the Hub Version and YouTrack Version are hidden.
If the Product name is YouTrack, the field that stores the YouTrack Version is shown.
If the Product name is Hub, the fields that store the Hub Version and YouTrack Version are shown.
For more information, see Conditional Custom Fields.
Private Fields
Custom fields have a setting that determines whether they are private or public. When a custom field is marked as private, only users with the Read Issue Private Fields or Update Issue Private Fields permissions in the project can view or edit the field, respectively.
When a field is public, any user who has the Read Issue or Update Issue permissions in the project can view or edit the field.
This feature helps restrict access to data in the following ways:
It can be used to hide fields that store sensitive information, like personal data.
It limits the number of users who can edit the values in a field. For example, it can let users view the current assignee, but only managers can reassign issues.
If you don't have permission to read private fields, you can't see them in the issue. If you have permission to view but not update private fields, the values are shown but the controls are hidden. If you attempt to modify the value by clicking the field, an error is shown.
For more information, see Private Custom Fields.
Workflow-driven Fields
A project administrator can attach a workflow to a project that regulates the transitions from one value to another for a custom field. These transitions are regulated by state-machine rules. State-machine rule can be applied to any custom field. However, the most common use case for a state-machine rule is to regulate transitions between values for the State field or another custom field that stores a state type.
When a state-machine rule is applied to a project, the options that are shown in the drop-down list for the field are restricted to the transitions that are defined in the state-machine rule for the current state. Custom fields that are regulated by a state-machine rule are marked with a Workflow-driven field icon.
The action that is defined for each value in the state-machine rule is displayed in the drop-down list. The actual values are shown to the right.
For more information, see State-machine Rules.
Calculated Fields
When the Time Tracking feature is enabled in a project, the project administrator can choose which field stores the amount of cumulative spent time for an issue. This field records the total amount of time that is reported for all work items in the issue. You cannot update this value manually — only by adding or editing work items. If you attempt to update the value in this field manually, an error is shown.
For issues that are linked as the parent for other issues, YouTrack automatically calculates the estimation and spent time as the sum of values that are added to each subtask.
If you add work items to a parent task, the spent time in the parent task includes spent time from work items that are added to the parent task plus the total spent time for each of its subtasks. For this reason, we generally recommend that you avoid adding work items to parent tasks.
If you change the estimation for a parent task, the synchronization between the parent task and its subtasks is broken. To restore the synchronization and calculate the estimation for the parent task automatically, set the estimation value in the parent task to the total estimation for each of its subtasks.
For more information, see Spent Time Calculations.
Assignees
Each project has a collection of users who are available in the set of values for the Assignee field. As long as an administrator has not redefined the behavior of this field, the set of values for the Assignee field in a new project includes all of the members of the project team.
Project administrators can manage the list of assignees independently from the project team. They can remove team members who should not be assigned issues in the project, or add users who don't belong to the project team. For more information, see Manage Assignees.
The default Assignee field stores a single value. This means that issues can only be assigned to a single user. However, an administrator can update the base properties of this field to store multiple values. For details, see Assign Issues to Multiple Assignees.
Owned Fields
Fields that store values as an ownedField have a secondary Owner property. This property associates each value in the field with a specific user. The default Subsystem field uses this data type.
This secondary property is not visible in the list of values for the field. However, it is accessible to workflows. You can script workflows that react to changes to the value for an owned field and perform operations related to its owner. For example, if you set the value for this field in a project that uses the Subsystem Assignee workflow, the issue is automatically assigned to the user who is set as the subsystem owner.
Version Fields
Fields that store values as a version have a collection of secondary properties. Each value that is stored in the field can be assigned a release date, flagged as released, and flagged as archived.
A common practice for teams that follow the Scrum methodology is to synchronize sprints with a release version of the product. YouTrack supports this practice with agile boards that can link sprints to values for a custom field.
If you manage issues in a project using an agile board that was built with the Version-based Board or is otherwise configured to link sprints to the values that are stored in the Fix versions field, it's possible to update the value for the Fix versions field by moving issues between sprints. The synchronization between sprints and field values works the other way around as well. When you update the value for the Fix versions field in an issue, the issue is automatically assigned to the corresponding sprint. To learn more, see Link Sprints with Fix Versions.
Build Fields
Many projects for software development will include one or more fields that store a build number as a build type. Each value that is stored in the field can be assigned an assemble date. This is mostly used for sorting values chronologically in the set.
While it is possible to manually add values to a field that stores a build number, most are populated automatically by a build server integration. For example, projects that use the TeamCity integration assign build numbers to issues when a commit message that is processed by the integration mentions an issue. Build numbers in YouTrack are appended with an icon that provides direct access to the build in TeamCity.
If you manually assign a build number that has been processed by the integration to a field, the TeamCity icon is added to this field as well.
For more information, see Integrate with a Build Server.
Adding New Values to Fields
Each project can have a distinct set of values that are stored in custom fields that store enumerated values. Users who have Update Project permission in all of the projects that use a field can add values to enumerated sets without navigating away from an issue.
For fields that are unique to your project or that use an independent set of values, you only need Update Project permission in the current project. When this is the case, you see the option to add a new value at the bottom of the list of existing values.
Working with Archived Values
In most fields that store values from an enumerated set, there is an option to archive specific values in the set.
Values that are marked as archived are not available in the drop-down list for custom fields. This means that you can't set the value for the field to an archived value directly in the user interface.
If one or more values that are currently assigned to the field are archived, you can clear the selection to remove these values from the field. Archived values are shown with a archived badge in the drop-down list.
Archived versions are still available to commands, workflows, and the REST API. This means that you can use commands to add or remove archived values or update these values programmatically. To learn more about updating issues with commands, see Apply Commands to Issues.
