Workflow Rules
YouTrack provides three different types of workflow rules. The rule type defines the general conditions that cause the rule to be executed.
Stateless Rules
A Stateless Rule defines the action to be performed when a change is applied to an issue. The rule defines the guard condition that must be met for the rule to be executed.
A stateless rule is executed by the user who applies the change that matches the guard condition.
Sample Stateless Rule
This rule performs the following actions when a change is applied to an issue:
- YouTrack checks for a change to the value in the Subsystem field.
- If the value in the Subsystem changed, the issue is automatically assigned to the owner of the subsystem.
rule Set Assignee to a Subsystem Owner
when issue.Subsystem.changed {
issue.Assignee = issue.Subsystem.owner;
}Scheduled Rules
A Scheduled Rule defines a schedule of events depending on a guard condition. For example, you can periodically check for issues with specific attribute values and notify a user or a group.
A scheduled rule is executed by a special workflow user. This is a system user account that is granted a full set of permissions. The permissions for this account cannot be modified. The workflow user account is not included in the license restrictions and is not displayed in the users list.
The guard conditions that you can use in a scheduled rule are limited.
You can only use queries that are optimized by the database.
These include queries that reference specific fields (for example, issue.Priority == {Critical} or issue.Due Date > now).
A guard condition that uses a method or operation (for example, issue.isResolved()) requires significant system resources to process.
Guard conditions that contain methods or operations in the expression are not supported.
Sample Scheduled Rule
This rule defines a schedule for the following periodic action:
- Each day at 08:00, YouTrack checks issues that contain a value in the Due date field. If the issue is due in fewer than two days, a notification is sent to the assignee. The notification is formatted as follows:
schedule rule Check for Due date and notify assignee
daily at 08 : 00 : 00 [issue.Due date <= (now + 2 days)] {
issue.Assignee.notify("Issue is due in less than two days", "You have less than two days remaining to resolve the following issue:" + issue.getId());
}The schedule uses the date constant 08 : 00 : 00, which uses the time zone setting for your YouTrack server.
The issue.Due date references a custom field that stores the date and time as 12:00 UTC.
If, for example, your office is in California (UTC-7) and you want your users to be notified for all issues that are due in less than two days,
you need to offset the due date by seven hours.
For more information, see Working with Dates and Times.
State-machine Rules
A State-machine Rule defines transitions between issue states. A state here is not only the State field of an issue, but any field of an issue that has defined transitions from one value to another. However, the most obvious and most often used state-machine rule is for transitions between values of the State field.
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 actions defined in the state-machine rule.
State-machine rules have two types of conditions.
- The conditions
enter,exit, andonperform an action when the value for the field is set. These conditions are executed by the user who changes the value of the field. - The condition
inperforms an action after the specified time frame. These conditions are executed by the workflow user account.
Sample State-machine Rule
This rule defines the following transitions for the State field of an issue:
- An issue starts with the state Submitted.
- From the initial state, an issue can only transition to the following state:
- From the Open state, an issue can only transition to the following state:
- From the Fixed state, an issue can only transition to the following state:
- From the Duplicate and Can't Reproduce states, the issue can only transition to Reopened.
- From the Reopened state, the issue can only transition to Fixed.
statemachine State lifecycle for field State {
initial state Submitted {
on Open[always] do {<define statements>} transit to Open
}
state Open {
on Fix[always] do {<define statements>} transit to Fixed
on Duplicate[always] do {<define statements>} transit to Duplicate
on Can't reproduce[always] do {<define statements>} transit to Can't Reproduce
}
state Fixed {
enter {
issue.Subsystem = {Testing};
}
on Verify[always] do {<define statements>} transit to Verified
on Reopen[always] do {<define statements>} transit to Reopened
}
state Verified {
}
state Reopened {
on Fix[always] do {<define statements>} transit to Fixed
}
state Duplicate {
on Reopen[always] do {<define statements>} transit to Reopened
}
state Can't Reproduce {
on Reopen[always] do {<define statements>} transit to Reopened
}
}