Adding an issue field
Standard issue fields
The most popular issue fields (settings) are available in Tracker by default. You can see the list of existing fields on the Settings Tracker page.
If you can't find a relevant parameter among them, you can create a new field in your queue. If you want to add a field that will be available in all Tracker queues, admin can create a global field.
| Issue field | Description |
|---|---|
| System | |
| QA engineer | User assigned to test the issue. |
| Author | User who created the issue. |
| Possible spam | Spam flag for issues created through services with integration. |
| End Date | Date when work on the issue was completed. |
| Start Date | Date when work on the issue started. |
| Deadline | Date by which the issue must be resolved. |
| Boards | List of boards the issue appears on. |
| Access | List of users who can read and edit the issue but do not receive notifications of changes. The issue access permissions are determined by the queue settings. |
| Summary | Issue name. |
| Modifier | User who last modified the issue. |
| Assignee | User who will work on the issue. |
| Fix Version | Product version the issue belongs to. The list of available versions is determined by the queue settings. |
| Key | Unique ID of the issue within the queue. It is generated automatically. |
| Number of comments without message | Number of issue comments created in Tracker. |
| Number of comments with message | Number of issue comments created via email. |
| Components | Labels that can be used to mark up and sort the issues within the queue. The list of available components is determined by the queue settings. |
| Followers | List of users subscribed to the issue. By default, they can read and edit the issue and receive notifications of all changes. The issue access permissions are determined by the queue settings. |
| Affected Version | Product version the issue belongs to. The list of available versions is determined by the queue settings. |
| Pending reply from | List of users invited to comment on the issue. As soon as a user responds, their name is removed from this field. |
| Updated | Date and time the issue was last updated. |
| Description | Issue statement: a description of what needs to be done. |
| Queue | Key of the queue that contains the issue. |
| Last Comment | Date and time the issue was last commented on. |
| Priority | Importance of the issue. |
| Voted | List of users who voted for the issue. |
| Votes | Number of users who voted for the issue. |
| Project | Names of projects the issues belongs to. |
| Resolved | Date and time the issue was marked as resolved. |
| Maillists | Teams and departments subscribed to the issue. By default, they can read and edit the issue and receive notifications of all changes. The issue access permissions are determined by the queue settings. |
| Resolution | Reason for closing the issue. |
| Resolver | User who marked the issue as resolved. |
| Created | Date and time the issue was created. |
| Status | Current progress on the issue. For example: Open, In progress, Testing. For more information, see Setting up statuses. |
| Last status change | Date and time the issue status was last changed. |
| Tags | Text labels that make sorting and searching for issues easier. For more information, see Structuring issues. |
| Type | Type of the issue, e.g., New feature, Bug, or Improvement. For more information, see Issue types. |
| Time Tracking | |
| Time Spent | Time the assignee spent resolving the issue. |
| Estimate | Time the user plans to spend on the issue. The field value decreases when the time spent is specified. |
| Original Estimate | Initial estimation of time needed to resolve the issue. |
| Agile | |
| Story Points | Issue complexity in Story Points. For more information, see Basic concepts of agile development. |
| Sprint | Name of the sprint the issue belongs to. |
| Email To | Full list of recipients the user specified in the To field when sending the email. |
| Email Cc | Email address the user specified in the CC field when sending the email. |
| Email From | Email address of the sender. |
| Created By email to | Email address that received the email from which the issue was generated. |
| SLA | |
| SLA | Timer that tracks the time for processing issues in the queue. For example, you can set the time within which the assignee has to respond to a new issue. For more information, see SLA. |
Local fields
If you need to add a new issue field that is not available in Tracker, you can add local fields to your queue.
A local field can only be used in the issues of the queue it's linked to. The advantage of local fields is that the queue owner can manage them without the risk of affecting the workflows in other queues. Users working in other queues will not see this field in their issues.
For more information about creating and using local fields, see Local issue fields.
Alert
Local fields are temporarily not supported in certain cases. Such support will be implemented later. For more information, see Local field constraints.
Global fields
Adding a global field
Alert
Only an administrator can add global fields.
To add a new issue field (parameter):
-
Make sure you are authorized as an administrator.
-
On the left-hand panel, select Administration → Tracker setting .
-
Go to the Fields tab.
-
Click Create field.
-
Select the field type and click Continue.
-
Set parameters for a new field:
-
Category: All Tracker fields are grouped into categories. Select the category that best suits the new field.
-
Name: Try to give short and concise names to your fields.
-
Name in English: This name is shown in the English interface of Tracker.
-
Type of number (only for fields with the Number type).
-
List items (only for the Drop-down list fields): Enter the possible values and their order.
-
Item selection (only for the Drop-down list fields).
-
Number of employees (only for the User list fields).
-
-
Click Create.
Edit a global field
Editing the parameters of a global issue field isn't supported in the Tracker web interface. For this purpose, use requests to Yandex Tracker API:
-
HTTP request for renaming a global field.
-
HTTP request for changing the acceptable values of a global field.
Delete a global field
You can't delete a global field, but you can hide it in the Tracker interface. For this, in the body of the request to Yandex Tracker API for changing the global field, set the hidden parameter to true.
You can't add a hidden field to an issue using the right panel.