Update Field Values

Smart Links in String-type Fields

In fields that store strings of text, YouTrack automatically recognizes when the value entered in the field is a URL.

When you enter a web address into a field that stores a string, YouTrack displays a special icon next to the value in the field. Users can click this icon to open the target link in a new browser tab.

Formatted Text Fields

YouTrack supports custom fields that store values as text with formatting. These fields store a string of characters that is presented as formatted text 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. The ability to add and edit content in these fields is supported by a rich text editor. The editor lets you format text in Visual or Markdown mode. When editing in Markdown mode, a preview of the formatted input is shown below the field.

• To learn more about formatting text in YouTrack, see Rich Text Editor.

• For a complete list of formatting options in Markdown, see Markdown Syntax.

Aside from their formatting options and location in the issue form, working with formatted text fields is just like any other custom field in YouTrack.

• To learn how to add fields to a project, see Add a New Custom Field.

• To learn more about fields that store values as formatted 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.

If you attempt to create an issue without setting values for required fields, the required fields are highlighted in the issue.

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 Publication.

• If the field is empty, 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 for updating the values are hidden.

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.

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.

Fields that Show Spent Time

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.

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 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.

Moving Issues Between Projects

When you need to move an issue from one project to another, click the Project field and select the target project in the dropdown.

When you move an issue to another project, the following happens:

• The ID of the issue changes. The issue gets a new ID with the prefix of the target project and the next consecutive issue number in the target project. The old link to the issue will now redirect to the new link with the new ID.

  For example, if you move an issue from the ABC project to XYZ, the issue ID will change from ABC-123 to XYZ-1234. The old link to https://example.youtrack.cloud/youtrack/issue/ABC-123 will now redirect to https://example.youtrack.cloud/youtrack/issue/XYZ-1234.

• YouTrack handles the custom field values as follows:

  • If a custom field is not added to the target project, its value is erased from the issue. If you move the issue back to the original project, the initial value won't be restored.

  • If a custom field is present in the target project and its set of values contains the same field value as the issue has, YouTrack preserves the value in the issue.

  • If a custom field is present in the target project but its set of values doesn't contain the value in question, YouTrack resets the field value in the issue to the default value.

• The workflows and other automations that are configured in the target project may trigger. Before moving, ensure that you're aware of the possible consequences.

• If you don't have enough permissions in the target project, you won't be able to update the issue after the move. In such cases, you will need to contact the administrator of the target project to update the issue or move it back to the original project.

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 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 below 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 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.