Product SiteDocumentation Site

4.3. Workflow

Now that we have covered how an issue gets created, and what are the different statuses during the life cycle of such issues, the next step is to define the workflow. The workflow dictates the valid transitions between statuses and the user access level required of the user who triggers such transitions; in other words, how issues move from one status to another and who is authorized to trigger such transitions.
MantisBT provides the ability for teams to define their own custom workflow which works on top of their custom status (see Section 7.5, “Customizing Status Values”).

4.3.1. Workflow Transitions

By default, there is no workflow defined, which means that all states are accessible from any other, by anyone.
The "Manage > Manage Configuration > Workflow Transitions" page allows users with ADMINISTRATOR access level to do the following tasks:
  • Define the valid next statuses for each status.
  • Define the default next status for each status.
  • Define the minimum access level required for a user to transition to each status.
  • Define the default status for newly created issues.
  • Define the status at which the issue is considered resolved. Any issues a status code greater than or equal to the specified status will be considered resolved.
  • Define the status which is assigned to issues that are re-opened.
  • Define the required access level to change the workflow.
Note that the scope of the applied change is dependent on the selected project. If "All Projects" is selected, then the configuration is to be used as the default for all projects, unless overridden by a specific project. To configure for a specific project, switch to it via the combobox at the top right corner of the screen.
The Global ("All Projects") workflow can also be defined in the config_inc.php file, as per the following example.
$g_status_enum_workflow[NEW_]           ='30:acknowledged,20:feedback,40:confirmed,50:assigned,80:resolved';
$g_status_enum_workflow[FEEDBACK]       ='30:acknowledged,40:confirmed,50:assigned,80:resolved';
$g_status_enum_workflow[ACKNOWLEDGED]   ='40:confirmed,20:feedback,50:assigned,80:resolved';
$g_status_enum_workflow[CONFIRMED]      ='50:assigned,20:feedback,30:acknowledged,80:resolved';
$g_status_enum_workflow[ASSIGNED]       ='80:resolved,20:feedback,30:acknowledged,40:confirmed';
$g_status_enum_workflow[RESOLVED]       ='90:closed,20:feedback,50:assigned';
$g_status_enum_workflow[CLOSED]         ='20:feedback,50:assigned';


The workflow needs to have a path from the statuses greater than or equal to the 'resolved' state back to the 'feedback' state (see $g_bug_resolved_status_threshold and $g_bug_feedback_status under Section 5.22, “Status Settings”), otherwise, the re-open operation won't work.


The first item in each list denotes the default value for this status, which will be pre-selected in the Change Status combobox in the View Issues page.