Workflows

Configure which issue status transitions are allowed for each role and tracker, and which fields each role can edit in a given status.

Workflows define the rules for how issues move through statuses. They have two dimensions:

1. Status transitions — which status changes a role can make on issues of a given tracker.
2. Field permissions — which fields a role can edit when an issue is in a given status.

Workflows are always scoped to a combination of tracker and role.

Status transitions

A status transition rule (WorkflowTransition) records that a role can move an issue from one status to another on a specific tracker.

Transition rules

Each transition can apply in three contexts:

Rule	When it applies
Always	The transition is allowed for any user with the role, regardless of their relationship to the issue (author = false, assignee = false).
Author only	Only the user who created the issue can make this transition (author = true).
Assignee only	Only the user the issue is assigned to can make this transition (assignee = true).

When both Author and Assignee are checked, the transition is allowed if the current user is either the author or the assignee.

Configuring transitions

1. Open the Workflow editor

   Go to Administration → Workflows and select a Tracker and a Role from the dropdowns, then click Edit.

2. Read the matrix

   The page shows a matrix where rows are the current status (old status) and columns are the target status (new status). A checked cell means the role can move an issue from that row’s status to that column’s status.

   The first row represents new issues (no prior status). Checking a cell in this row means the role can create issues directly in that status.

3. Check or uncheck transitions

   Check cells to allow a transition. Three checkboxes appear per cell: Always, Author, and Assignee.

4. Save

   Click Save to apply the workflow rules.

Start by configuring the Manager role with all transitions enabled. Then configure Developer and Reporter with progressively restricted transitions.

Field permissions

The Fields permissions tab in the workflow editor controls which fields a role can edit on an issue of a given tracker when the issue is in each status.

Possible permission values per field per status:

Permission	Meaning
(blank)	Inherits the default editability. The role can edit the field if it has edit_issues permission.
Read-only	The field is displayed but cannot be edited, even if the role normally has edit access.
Required	The field must be filled in before the issue can be saved in this status.

Field permissions only apply to roles that have the add_issues or edit_issues permission. Roles without those permissions cannot edit issue fields regardless of workflow field permissions.

Copying workflows

Instead of configuring transitions from scratch, you can copy an existing workflow:

1. Open the Copy form

   Go to Administration → Workflows and click Copy.

2. Select the source

   Choose the source Tracker and source Role whose workflow you want to copy.

3. Select the targets

   Choose one or more target trackers and roles. The copy replaces any existing workflow rules for the selected combinations.

4. Apply

   Click Copy. WorkflowRule.copy deletes existing rules for the target combinations and inserts copies from the source.

Copying a workflow overwrites the existing rules for the selected target tracker/role combinations. This cannot be undone from the UI.

Workflow summary

To get an overview of all configured workflows, go to Administration → Workflows and click Summary. The summary shows a matrix of trackers versus roles, indicating which combinations have transitions configured.

Relationship between workflows and roles

A role is considered to “use” the workflow system if it has either the add_issues or edit_issues permission. Roles without those permissions are excluded from workflow copying and are shown as inactive in the workflow summary.

Example: typical workflow setup

New → In Progress    (Developer, always)
New → Rejected       (Manager, always)
In Progress → Resolved  (Developer, always; Reporter, assignee only)
Resolved → Closed    (Manager, always; Reporter, author only)
Resolved → In Progress  (Developer, always)  ← reopen
Closed → In Progress    (Manager, always)     ← reopen from closed

In this setup:

• Developers move work forward.
• Managers can reject, close, and reopen from any state.
• Reporters can resolve issues assigned to them but cannot close.