A number of pages exist under the "Manage" link. These will only be visible to those who have an appropriate access level.
This page allow an administrator to manage the users in the system.It essentially supplies a list of users defined in the system. The user names are linked to a page where you can change the user's name, access level, and projects to which they are assigned. You can also reset their passwords through this page.At the top, there is also a list of new users (who have created an account in the last week), and accounts where the user has yet to log in.New users are created using the "Create User" link above the list of existing users. Note that the username must be unique in the system. Further, note that the user's real name (as displayed on the screen) cannot match another user's user name.
This page allows the user to manage the projects listed in the system.Each project is listed along with a link to manage that specific project. The specific project pages allow the user to change:
the project name
the project description
its status
whether the project is public or private. Private projects are only visible to users who are assigned to it or users who have the access level to automatically have access to private projects (eg: administrators).
afile directory used to store attachments for issues and documents associated with the project. This folder is located on the webserver, it can be absolute path or path relative to the main Mantis folder. Note that this is only used if the files are stored on disk or via FTP. In case of FTP, the cached version that is saved on the webserver, is stored in the specified path.
common subprojects. These are other projects who can be considered a sub-project of this one. They can be shared amongst multiple projects. For example, a "documentation" project may be shared amongst several development projects.
project categories. These are used to sub-divide the issues stored in the system.
project versions. These are used to create ChangeLog reports and can be used to filter issues. They are used for both the Found In and Fixed In versions.
Custom Fields linked to this project
Users linked to this project. Here is the place where a user's access level may be upgraded or downgraded depending on their particular role in the project.
This page is the base point for managing custom fields. It lists the custom fields defined in the system. There is also a place to enter a new field name to create a new field.The "Edit" links take you to a page where you can define the details of a custom field. These include it's name, type, value, and display information. On the edit page, the following information is defined to control the custom field:
name
type. Possible values are listed below.
Value constraints (Possible values, default value, regular expression, minimum length, maximum length).
Access (who can read and write the field based on their access level).
Display control (where the field will show up and must be filled in
All fields are compared in length to be greater than or equal to the minimum length, and less than or equal to the manimum length, unless these values are 0. If the values are 0, the check is skipped. All fields are also compared against the regular expression. If the value matches the expression, then the value is stored. For example, the expression "/^-?([0-9])*$/" can be used to constrain an integer.The table below describes the field types and the value constraints.
| Type | Field Contents | Value Constraints |
| String | text string up to 255 characters | |
| Numeric | an integer | |
| Float | a floating point number | |
| Enumeration | one of a list of text strings | Enter the list of text strings separated by "|" (pipe character) in the Possible Values field. The Default value should match one of these strings as well. This will be displayed as a dropdown menu. |
| an email address string up to 255 characters | When displayed, the value will also be encapsulated in a mailto: reference. | |
| Checkbox | zero or more of a list of text strings | Enter the list of text strings separated by "|" (pipe character) in the Possible Values field. The Default value should match one of these strings as well. This will be displayed as a list of text strings with a checkbox beside them. |
| List | one of a list of text strings | Enter the list of text strings separated by "|" (pipe character) in the Possible Values field. The Default value should match one of these strings as well. This will be displayed as a multi-line dropdown menu. |
| Multiselection List | zero or more of a list of text strings | Enter the list of text strings separated by "|" (pipe character) in the Possible Values field. The Default value should match one of these strings as well. This will be displayed as a multi-line dropdown menu. |
| Date | text string defining a date | This is displayed as a set of dropdown menus for day, month, and year. Defaults should be defined in yyyy-mm-dd format. |
The display entries are used as follows:
| Entry | Meaning |
| Display Only On Advanced Page | If checked, the field will NOT be shown on the simple bug displays |
| Display When Reporting Issues | If checked, the field will be shown on the report issues displays |
| Display When Updating Issues | If checked, the field will NOT be shown on the update issue and change status displays |
| Display When Resolving Issues | If checked, the field will NOT be shown on the update issue displays and change status displays, if the new status is resolved. |
| Display When Closing Issues | If checked, the field will NOT be shown on the update issue displays and change status displays, if the new status is closed. |
| Required On Report | If checked, the field must be filled in on the issue reports. |
| Required On Update | If checked, the field must be filled in on the update issue and change status displays. |
| Required On Resolve | If checked, the field must be filled in on the update issue and change status displays, if the new status is resolved. |
| Required On Close | If checked, the field must be filled in on the update issue and change status displays, if the new status is closed. |
Notes on Display
Be careful not to set both a required attribute and show only on advanced display. It may be possible to trigger a validation error that the user cannot recover from (i.e., field is not filled in).
This page allows the definition of global profiles accessible to all users of the system. It is similar to the user definition of a profile consisting of Platform, OS and Version.
This set of pages control the configuration of the Mantis system. Note that the configuration items displayed may be on a project by project basis.These pages serve two purposes. First, they will display the settings for the particular aspects of the system. If authorized, they will allow a user to change the parameters. They also have settings for what access level is required to change these settings ON A PROJECT basis. In general, this should be left alone, but administrators may want to delegate some of these settings to managers.
This page covers the adjustment of the settings for many of the workflow related parameters. For most of these, the fields are self explanatory and relate to a similarly named setting in the configuration file. At the right of each row is a selector that allows the administrator to lower the access level required to change the particular parameter.The values changeable on this page are:
Issues.
| Title | Variable | Description |
| Report an Issue | $g_report_bug_threshold | threshold to report an issue |
| Status to which a new issue is set | $g_bug_submit_status | status issue is set to when submitted |
| Update an Issue | $g_update_bug_threshold | threshold to update an issue |
| Allow Issue to be closed on Resolve | $g_allow_close_immediately | allow close immediately on resolve |
| Allow Reporter to close an issue | $g_allow_reporter_close | allow reporter to close issues they reported |
| Monitor an issue | $g_monitor_bug_threshold | threshold to monitor an issue |
| Handle Issue | $g_handle_bug_threshold | threshold to handle (be assigned) an issue |
| Assign Issue | $g_update_bug_assign_threshold | threshold to be in the assign to list |
| Move Issue | $g_move_bug_threshold | threshold to move an issue to another project. This setting is for all projects. |
| Delete Issue | $g_delete_bug_threshold | threshold to delete an issue |
| Reopen Issue | $g_reopen_bug_threshold | threshold to reopen an issue |
| Allow reporter to reopen Issue | $g_allow_reporter_reopen | allow reporter to reopen issues they reported |
| Status to which a reopened Issue is set | $g_bug_reopen_status | status issue is set to when reopened |
| Resolution to which a reopened Issue is set | $g_bug_reopen_resolution | resolution issue is set to when reopened |
| Status where an issue is considered resolved | $g_bug_resolved_status_threshold | status where bug is resolved |
| Status where an issue becomes read-only | $g_bug_readonly_status_threshold | status where bug is read-only (see update_readonly_bug_threshold) |
| Update readonly issue | $g_update_readonly_bug_threshold | threshold to update an issue marked as read-only |
| Update Issue Status | $g_update_bug_status_threshold | threshold to update an issue's status |
| View Private Issues | $g_private_bug_threshold | threshold to view a private issue |
| Set View Status | $g_set_view_status_threshold | threshold to set an issue to Private/Public |
| Update View Status | $g_change_view_status_threshold | threshold needed to update the view status while updating a bug or a bug note |
| Show list of users monitoring issue | $g_show_monitor_list_threshold | threshold to see who is monitoring an issue |
| Set status on assignment of handler | $g_auto_set_status_to_assigned | change status when an issue is assigned |
| Status to set auto-assigned issues to | $g_bug_assigned_status | status issue is set to when assigned |
| Limit reporter's access to their own issues | $g_limit_reporters | reporters can see only issues they reported. This setting is for all projects. |
Notes.
| Title | Variable | Description |
| Add Notes | $g_add_bugnote_threshold | threshold to add a bugnote |
| Update Notes | $g_update_bugnote_threshold | threshold to edit a bugnote |
| Allow users to edit their own bugnotes | $g_bugnote_allow_user_edit_delete | can a user edit/delete their own bugnotes |
| Delete Note | $g_delete_bugnote_threshold | threshold to delete a bugnote |
| View private notes | $g_private_bugnote_threshold | threshold to view a private bugnote |
Others.
| View Change Log | $g_view_changelog_threshold | threshold to view the changelog |
| View Assigned To | $g_view_handler_threshold | threshold to see who is handling an issue |
| View Issue History | $g_view_history_threshold | threshold to view the issue history |
| Send Reminders | $g_bug_reminder_threshold | threshold to send a reminder |
This page covers the status workflow. For most of these, the fields are self explanatory and relate to a similarly named setting in the configuration file. At the right of each row is a selector that allows the administrator to lower the access level required to change the particular parameter.The values changeable on this page are:
Table 1. Issues
| Title | Variable | Description |
| Status to which a new issue is set | $g_bug_submit_status | status issue is set to when submitted |
| Status where an issue is considered resolved | $g_bug_resolved_status_threshold | status where bug is resolved |
| Status to which a reopened Issue is set | $g_bug_reopen_status | status issue is set to when reopened |
The matrix that follows has checkmarks where the transitions are allowed from the status on the left edge to the status listed across the top. This corresponds to the $g_enum_workflow array.At the bottom, there is a list of access levels that are required to change the status to the value listed across the top. This can be used, for instance, to restrict those who can close an issue to a specific level, say a manager. This corresponds to the $g_set_status_threshold array and the $g_report_bug_threshold setting.
This page sets the system defaults for sending emails on issue related events.Mantis uses flags and a threshold system to generate emails on events. For each new event, email is sent to:
the reporter
the handler (or Assigned to)
anyone monitoring the bug
anyone who has ever added a bugnote the bug
anyone assigned to the project whose access level matches a range
the originator of the change, if $g_email_receive_own is OFF
the recipient either no longer exists, or is disabled
the recipient has turned their email_on_<new status> preference OFF
the recipient has no email address extered