Please log in to subscribe to updates for this article
Last updated at Mon Aug 13 07:07, by zegenie
Workflow step explained ⇑ topA workflow consists of several steps, together defining the possible states an issue can be in during the issue lifecycle. A step is linked to the following three separate properties of an issue:
- Whether the issue is editable
- Whether the issue is closed
- (optionally) The issue status ("Fixed", "In progress", "Testing", etc)
Editable / not editable ⇑ topThe editable flag is used to determine whether the basic details of the issue can be changed or not. If a workflow step is marked as not editable, you cannot change the title, description or reproduction steps. This can be used to force a workflow where you can trust that once an issue is "confirmed", it cannot be changed. In the Default workflow, this is enforced once an issue is moved into the "Confirmed" step.
Closed / open ⇑ topThe closed or open setting determines whether an issue is marked as closed or open once it enters that workflow step. Closed issues appear in the "closed issues" searches, whereas open issues appear in the "open issues" searches. Closed issues also determine the state of any linked milestones - that is, if all issues in a milestone are marked as closed, the milestone is marked as reached. This is used to determine whether milestones are overdue or completed in time. Closed issues can also not be edited, similar to the not editable workflow step flag.
Issue status ⇑ topYou can use the workflow step to change the issue status. F.ex. a workflow step called "Confirmed" can be linked to the status "Confirmed". This way you can easily distinguish the different statuses issues are in when searching for issues. A workflow step can also not be linked to any status - this can be useful if you don't want to force a status when moving an issue between workflow steps.
Linking to more than one status ⇑ topA workflow step can also be linked to more than one status. This can be done by setting up the workflow transition post-transition validation so that only a specific set of statuses can be chosen. In the default workflow, this is used in the "Reject issue" and "Resolve issue" transitions, as an issue can be rejected or resolved in different ways, where the "Resolution" field may not be sufficient to indicate the resolution.
Changing issue workflow step ⇑ topAn issue can only enter a new step via a transition (either instantly or via a transition view), which often defines other properties that needs to be set in order for the issue to progress to the defined step. For the issue to progress, a transition from the current step to any other step in the workflow needs to be defined in the workflow itself.
An example of this is such as when an issue is in the initial step (often linked with the status "New"), a transition can take it to the "Confirmed" step (often linked with the corresponding "Confirmed" status). During this transition, a user or developer may be asked to provide additional details to validate the transition. How transitions work are explained in more detail in the transitions documentation.
The workflow step is not visible anywhere on the issue - the way to tell it is usually to look at its state (open / closed) and the issues status field. This will give you an overview of the issues current position in the defined workflow.