Have you ever needed to let all your MantisHub users know about something? Perhaps a new process or procedure? Remind your reporters to make sure they include that vital information when they create issues. Running a customer survey? New release? Flag it to the team to check out the Changelog. Let everyone know (or maybe just your project team ; ) ) about Friday drinks. I’m sure you can think of a heap more.
MantisHub have just rolled out the new announcements plugin that allows you to create banners to be visible to your users within the MantisHub app. So you don’t need to use yet another medium to shout out to them. Some of our lovely customers have been asking for this. We totally get the advantages and are excited to deliver!
All administrators have access to install and configure the Announcements plugin. Just head to the plugins page in your MantisHub and check out our KB article for more step-by-step details. Within the configuration, Admins can define who is allowed to create banners according to access level. By default this is MANAGER level and above. You’ll probably want to keep the default. You don’t want just anyone sending out messages, but as with many MantisHub features, you have the flexibility to define it according to what suits your workflow.
Within the Announcement you can define the what, who, when and where for your banner.
What: Give it a title and message content. It can run across multiple lines and if you want, make use of Markdown to add formatting including emphasis and in-line links
Where: You can create a banner to be viewed across all projects or just for a single project and only users with access to that project will see the banner. Location will define where on the screen your message appears.
Who: Determine who sees your banner by defining the access level. Here you are setting the minimum access level for which the banner is viewable. For example, set it to ‘developer‘ and developers, manager and administrators will receive the banner. A users global access level will be applied for all project banners. For specific project banners, the system will use specific project access level if defined, otherwise it will use global access level. If a user does not have access to a private project, they will not see any banners defined for the project.
When: Set the time to live field to allow your banner to automatically disappear after your set time. A setting of 0 means your banner will remain up until you manually deactivate it, or the user dismisses it (if you’ve given them that option). The dismiss option is checked by default so once they’ve read or actioned it, your users can close the banner.
I’m sure you can see the benefit of this great new feature in MantisHub. I’m really excited about it. I’m planning to send out a joke of the week, maybe leave them hanging and create a separate banner for the punch line after a few days. I’ll let you know how it goes ;D. Go ahead and try it out. I’d love to hear how you’ve put it to use! Just tweet @mantishub with your ideas.
Til next time…
The main goal of issue tracking is to capture issues and drive them all the way to closure. A ticket is reported and our aim is to have it fixed or resolved and then close it off. Of course, each issue needs to progress through several stages before it reaches it’s final resting place and it’s important to clearly define your overall process for issue tracking and then to align this with the status at which an issue can be placed in at any particular point. This typically refers to your issue life-cycle.
MantisHub defines 7 statuses for you to reflect status of your issues. Below outlines how these statuses would be considered in a traditional software development process but you’ll see that much of this is transferable to any issue tracking scenario.
- New – This is the landing status for new issues and indicates it’s waiting on some review or action.
- Feedback – This status is used to reflect that the issue is pending on feedback from the reporter. So is used when more information is needed.
- Acknowledged – This status is used by the development team to reflect their agreement to the suggested feature request. Or as supporting what the reporter is suggesting.
- Confirmed – This status is typically used by the development team to reflect that they agree with what the reporter is suggesting in the issue and that they have confirmed and reproduced the issue.
- Assigned – This status is used to reflect that the issue has been assigned to one of the team members and that the team member is actively working on the issue.
- Resolved – This status is used to reflect that the issue has been resolved. For added information, an issue can be resolved with one of many resolutions. For example, an issue can be resolved as “fixed”, “duplicate” or “won’t fix”.
- Closed – This status reflects that the issue is completely closed and no further actions are required on it. It also typically hides the issue from the View Issues page. Some teams use “closed” to reflect sign-off by the reporter and others use it to reflect the fact that the fix has been released to customers.
Typically issues would move through new to closed but of course you may need to return to a previous status, for example a new development while in assigned state may require you to go back to feedback for some more information from the reporters. Or after resolution, the ticket needs to be re-opened. And some statuses may be skipped altogether, perhaps your smaller teams may not need to go through the acknowledged stage. Others may wish to skip resolved and go straight to closing the issue.
When determining your specific workflow and how they align to MantisHub statuses. It’s important to note that each of these 7 statuses map to one of 3 definite stages in an issues life as this will affect how MantisHub treats issues. For example,
- any status related filters use this (e.g. hide status field).
- Some workflow settings depend on these such as ‘when is an issue read-only’, and
- your resolution values need to make sense with the status value. Check out our KB article on valid combinations of status and resolution for details.
MantisHub determines this relationship by assigning a code to each of these statuses and using this to define the 3 stages.
- Open – at this stage, your issue is needing attention and actively being worked on. It will appear in filters and reports as open tickets. This stage covers the new through to assigned statuses or code values 0 to 79
- Resolved – at this stage your issue has been addressed but there may be some follow up (e.g. release, documentation, notifications etc). This stage contains the ‘Resolved’ status or code values 80 to 89.
- Closed – all work relating to this issue has been completed. This stage contains the closed status or code values 90 and above.
These stages and code values are particularly important if you’re considering customizing your status values.
Customizing your statuses
The 7 default status values do work really well for the vast majority of our customers. The terms are generic, intuitive and flexible enough to apply to any environment. However, we do offer the option to customize this for qualifying plans. The most simple changes are hiding any of the existing defaults that you find are not being used or changing the name or color for existing defaults. Not so straight forward but also commonly used are adding in some extra custom statuses.
When adding custom values here, there are 5 items of information you need to provide. While it’s tempting to just provide the new status name, you also need to define some peripheral terminology for the system such as what phrasing you want for email notifications. And it’s important to make sure to provide the requested terminology for any specific languages in which you use your system as these are not included in the system translations. All the details can be found in the KB article customizing issue statuses.
Another way to customize your workflow is by locking down transitions between each status. By default you can move freely from any status to another. But you may want to lock in certain behavior. For example, you may want the system to work such that once a new issue is changed to a higher status it can’t go back to being new. So you can disallow transition from any state back to ‘new’. Or perhaps you want to make sure all tickets go through the resolved state before being closed, so you would disallow all transitions to the closed state, except the transition from resolved state.
You can also lock down transitions according to a users access level. By default, developers and above are allowed to change an issue to each status, the only exception being that reporters can of course create issues in the ‘new’ status. There is simple check box configuration option to give reporters permission to re-open issues or close and this is configurable in the workflow thresholds.
To give you an example of making use of workflow transitions, lets say you want all managers to sign off on issues before they are closed, then you could set the minimum access level allowed to transition to closed status to be manager. Check out the article on workflow transitions for more details.
When using MantisHub Helpdesk to handle incoming customers tickets submitted via email, MantisHub suggest a number of tips and shortcuts as well as a specific workflow. In a customer support scenario, your issues or tickets will transition frequently between the feedback and assigned statuses. When responding to customers, you should set the status to feedback indicating you are waiting on a response from the customer. Once a customer replies, the ticket is automatically set to an assigned status indicating it’s waiting on your action. The workflow suggests a streamlined approach for handling these tickets and also takes into account which types of activity within the ticket will trigger notifications to your customers. Have a read of this article and many more on our Helpdesk feature for your customer support needs.
Addressing your workflow process and utilizing our intuitive issue life-cycle will definitely save your team time and money. Or consider tapping into the many ways you can tailor it to your needs. Improve efficiency and create simplicity in your issue tracking process and get closure :).