Mantis is a rather good open source bugtracker. Recently I’ve been using it across a small team working on a number of projects at once, and its going pretty well so far. It is especially useful when someone is testing something and someone else is bug-fixing. Today I’ve been looking at some changes to the user setup and thought I’d jot some notes here in case someone else finds it useful.

Altering who is allowed to do what

By clicking on the “Manage” and then “Manage Configuration” and then “Workflow Thresholds” links in Mantis, it is possible to alter which roles have access to which features. The roles available are:

• viewer
• reporter
• updater
• developer
• manager
• administrator

Unfortunately, these role names can’t be changed – What I need is one for IT people, one for management and designers, one for contract IT staff and one for project management people. I’ve ended up writing an accompanying document saying which people should have which level of access.

From this page you can turn on and off most functionality for the various levels of user. You can set who can resolve or delete issues, change statuses, assign issues and so on – and also which levels can see the notes or a list of who is monitoring the issue. This probably makes more sense in a large organisation, or where different people might be doing different roles for different projects. As we’re quite a small outfit then quite a lot of people have administrator access and almost all other users have at least the role “developer”.

Changing what triggers email notifications

Mantis sends out WAY too much email for our liking – so under “Manage” and then “Manage Configuration”, look for the “Email Notifications” tab. Here you can alter the settings and if you have the defaults set, you’ll see that nearly everyone has them ticked to start with! Its a neat interface with options for people reporting bugs, people with bugs assigned to them, and people monitoring bugs too. There is also functionality to include people who have added notes to the bug or people of a certain threshhold who have been assigned to that project, but I’m not using those right now.

How the status flows

Also at this level of configuration is a screen called “Workflow Transitions”, which allows you to set default status for new issues, and then dictate which statuses can follow on from which other statuses and what the default next status is for each. I’ve seen this before in other applications and its very useful to give a hint to the user as to what should be happening next in the project process. I thoroughly recommend that if you are setting up mantis, or even doing some housekeeping on an existing installation, you spend some time thinking about how this screen could be set up to make things faster for users.

Am I making sense?

I hope this is useful to someone – if nothing else it will be an excellent aide memoire for me next time I want to fiddle with the settings! Let me know if this was helpful or if there’s anything I’ve missed.