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. In other words, how issues move from one status to another and who has access to trigger such transitions. MantisBT provides the ability for teams to define their own custom workflow which works on top of their custom status. The workflow dictates the valid transitions between statuses and the user access level required of the user who triggers such transition.
This "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 with this 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 overidden by a specific project. To configure for a specific project, switch to the project via the combobox at the top right corner of the screen.
This "Manage > Manage Configuration > Workflow Thresholds" page allows users with ADMINISTRATOR access level to define the thresholds required to do certain actions. Following is a list of such actions and what they mean:
Report an issue - The access levels that are allowed to report an issue.
Update an issue - The access levels that are allowed to update the header information of an issue.
Allow issue to be closed on resolved - The access levels that are allow to resolve and close an issue in one step.
Allow reporter to close issue - Indicates if reporters should be allowed to close issues reported by them.
Monitor an issue - The access levels required for a user to be able to monitor an issue. Once a user monitors an issue, the user will be included in all future email notifications relating to changes in the issue.
Handle an issue - The access levels required for a user to be shown in the list of users that can handle an issue.
Assign an issue - The access levels required for a user to be able to change the handler (i.e. assign / unassign) an issue.
Move an issue - The access levels required for a user to be able to move an issue from one project to another. (TODO: are these access levels evaluated against source or destination project?).
Delete an issue - The access levels required for a user to be able to delete an issue.
Reopen an issue - The access levels required for a user to be able to re-open a resolved or closed issue.
Allow Reporter to re-open Issue - Whether the reporter of an issue can re-open a resolved or closed issue, independent of their access level.
Status to which a reopened issue is set - This is the status to which an issue is set after it is re-opened.
Resolution to which a reopen issue is set - The resolution to set on issues that are reopened.
Status where an issue is considered resolved - The status at which an issue is considered resolved.
Status where an issue becomes readonly - Issues with such status and above are considered read-only. Read-only issues can only be modified by users with a configured access level. Read-only applies to the issue header information as well as other issue related information like relationships, attachments, notes, etc.
Update readonly issues - The access levels required for a user to be able to modify a readonly issue.
Update issue status - The access levels required for a user to be able to modify the status of an issue.
View private issues - The access levels for a user to be able to view a private issue.
Set view status (public vs. private) - The access level for a user to be able to set whether an issue is private or public, when reporting the issue. If the user reporting the issues doesn't have the required access, then the issue will be created with the default view state.
Update view status (public vs private) - The access level required for a user to be able to update the view status (i.e. public vs. private).
Show list of users monitoring issue - The access level required for a user to be able to view the list of users monitoring an issue.
Set status on assignment of handler - The access levels required for a user to be able to re-assign an issue when changing its status.
Status to set auto-assigned issues to - The status - This is the status that is set on issues that are auto assigned to users that are associated with the category that the issuer is reported under.
Limit reporter's access to their own issues - When set, reporters are only allow to view issues that they have reported.
Add notes - The access levels required for users to be able to add notes.
Update notes - The access levels required for users to be able to update issue notes.
Allow user to edit their own bugnotes - A flag that indicates the ability for users to edit issue notes report by them.
Delete note - The access levels required for a user to delete a note that they may or may not have reported themselves.
View private notes - The access levels required for a user to be able to view private notes associated with an issue that they have access to view.
View Change Log - The access levels required for a user to be able to view the change log.
View Assigned To - The access levels required for a user to be able to know the handler of an issue that they have access to.
View Issue History - The access levels required for a user to be able to view the history of changes of an issue.
Send reminders - The access levels required for a user to be able to send reminders to other users relating to an issue that they have access to.