Attribute and field settings
This module manages visibility, editability, requiredness, default values, and other characteristics of built-in (system) and custom attributes. You can change their display order and description. The specified settings are used when displaying forms, lists, and boards.
Click the field name, or select the field to configure in the "Form fields" button located at the bottom left of the form.
| Setting name | Setting purpose |
|---|---|
| Default value |
As the default value of reference attributes you can specify a search query. This lets you select a default value that corresponds to some application logic. Also, using curly braces, you can substitute values of attributes of related entities, similar to how expressions are defined for calculated attributes. Example of an expression that forms the default value for the Text field of Requirements:
The first expression returns the content of the default template for the Requirement type. If no template is set, the second expression is evaluated: among the text templates of the current project, the default template for Requirements is selected and its content is used. |
| Constraint |
For reference attributes you can specify a query, which will be used as a filter. This can be used to limit the selection in drop-down lists. For example, offer for selection only current iterations, unfinished builds, Requirements of specific types only, and so on. In the query, a formula can be used as the right-hand expression. The system evaluates the formula and uses the resulting value to form the query that limits the selection. This way you can implement a dependency between fields on the form. For example, having specified the Task type, limit the selection of possible Assignees.
Here we limit the Assignee list based on the Assignee's project Role, which must match the Role in the project specified for the Task type. If you set Task type = Analysis, the system shows Assignees with the Role that corresponds to that Task type, and so on. |
| Regular expression |
To require the user to fill in a field value in a strictly defined format, use regular expressions. A regular expression starts with the "^" character, which denotes the beginning of the string, and ends with the "$" character, which denotes the end of the string. Examples of regular expressions:
|
| Visibility (condition) | If an attribute must be displayed only for certain values of other fields, for example only if Type = Bug, you can set a condition for the field visibility. The condition is a search query. If the search query is executed and returns an empty set, the attribute becomes hidden on the form; otherwise, the attribute is displayed. |
| Is required to be filled (condition) | As with Visibility, you can also control whether filling in the field is required, depending on the values of other fields set on the artifact form. |
Groups let you extend the attribute metadata, allowing the system to use attributes in different parts of the interface.
| Group name | Group purpose |
|---|---|
| trace | The attribute is displayed on the "Traceability" tab |
| deadlines | The attribute is displayed on the "Deadlines" tab |
| display-name | The attribute value is substituted into the project artifact name shown in links |
| tooltip | The attribute is shown in the tooltip when hovering over the project artifact ID |
| hours |
The attribute value represents units of time, so the interface automatically uses a representation such as 2d 3h and so on. |
| alternative-key | All attributes of the entity with this group are part of an alternate key. Such a key is used to determine the uniqueness of a record, including when importing data from Excel, in order to update an existing record instead of creating it. |
The main field settings can be overridden by settings for specific states or transitions, which are specified on the state and transition forms.
You can find the full list of all settings, with the ability to delete and edit them, in the "Form fields" module in the project Settings:
You can develop a PHP script that checks whether a field is filled in correctly, depending on any required conditions. If the condition is met, the script must return true, if not, then false. When the artifact card is saved, or when the value of this field is changed, the system runs the script and checks the condition. Depending on the result, the operation either succeeds, or the system reports that the validation condition for the field was violated. The validation functionality is available if you have a license for the "Script automation" module and configured rights for this module. Script execution results can be tracked in the Administration section, in the PHP scripts module.
Identifying project artifacts
You can define your own scheme for identifying artifacts, different from the one used in the system by default. To do this, open the settings of the "UID" attribute and set a formula there for calculating the default value.
As the formula for calculating the Requirement identifier, write an expression following the example from the description. Here are several variants of custom identification of Requirements:
- {PageType.ShortCaption,R}.{Id} - the Requirement ID starts with the short name of its type, for example, SR.123
- {PageType.ShortCaption,R}-{IdProject} - the "IdProject" field value is filled by an automatic counter within the project. In each project the counter starts at 1. This way you can get identifiers such as: BR-1, SR-2, and so on.
- {PageType.ShortCaption,R}-{IdType} - the "IdType" field value is filled by a counter for each Requirement type. This way you can get identifiers such as: BR-1, SR-1, and so on.
- {PageType.ShortCaption,R}-{IdHierarchy} - the "IdHierarchy" field value is filled by a counter within the hierarchy (document), that is, the counter increases for each next child element inside the document.
- {PageType.ShortCaption,R}-{IdParent} - the "IdParent" field value is filled by a counter within the parent section, that is, the counter increases for each next child element inside one section.
You can form an identifier using leading zeros; for example, given the expression {Id,6}, the system forms the identifier as 000001, 000002, and so on.