Custom workflows - Group configuration
- Many large companies need custom workflows as part of their issue management, as stated here: #1743.
- An example is that a team needs to ensure every single issue goes through exactly these stages: "To Do" > "In Dev" > "In QA" > "Code review" > "UAT" > "Ready for release" > "Post-production check".
- Per group, configure the custom workflow states for issues.
- Define allowable workflow states.
- State is different from workflow states.
- GitLab issues have only two states.
- When an issue is
Open, it can be in one of several customized workflow states.
- When an issue is
Closed, it doesn’t belong to any workflow state by definition. (I.e. its workflow state is null.)
- By default there are two customized workflow states called
Development. You can change the names of these workflow states. These two workflow states come as part of any new group created.
- When an issue is created, it starts in the first workflow state (part of the Open state) by default.
- You can create any number of workflow states per group, but you can only delete down to two workflow. I.e. minimum two workflow states per group.
- GitLab won't check if you use the same name for multiple workflow states.
- When you delete a workflow state, for all issues that were in that workflow state, they just go "backward" a stage. If the first workflow state was deleted, then all issues in that workflow state just go "forward" a workflow state.
- An issue takes the workflow states from its immediate parent group.
In the group configuration, we could have something like this, to allow an admin to configure the workflow states.
- In the future, an issue may take the workflow states of its ancestor groups. But its most immediate ancestor's workflow states will overload more older ancestors. This is important since if you are an issue, you may not appear in a given workflow board (&424), since you are not even in the relevant workflow states flow.
- Within an issue page, you will be able to see what workflow state it is in (only if it is
Open). And you can transition to another workflow state. Or simply close the issue.
- Issue lists and existing issue boards and burndowns work the same as now since there are still the same two defined states.
- There is a new group board type. This special board type has all lists predefined which are the custom stages. You can config the board as normal. But cannot add/remove lists. &424