Category: Uncategorized

MantisHub are ready for GDPR. Are you?

GDPR_04

 

MantisHub, like thousands of companies out there servicing EU citizens, have been preparing for the new EEA legislation around data privacy aka General Data Protection Regulation (GDPR).

Data privacy has not had this level of attention and stringency in decades. Now the EU has taken the lead and a huge step forward in making service providers accountable for the personal data that they collect as well as giving EU citizens (and by extension much of the rest of the world) more rights and greater control over their personal data and how service providers use it and store it.

As well as defining a high level of security and protection of personal data, the legislation included specific rights for EU consumers including:

  1. Right of Access: Find out what kind of personal information is held about you and get a copy of this information.
  2. Right of Rectification: Ask for your information to be updated or corrected.
  3. Right to Data Portability: Receive a copy of the information which you have provided under contract so that you can provide that information to another organization.
  4. Right to Restrict Use: Ask for your personal information to stop being used in certain cases, including if you believe that the personal information about you is incorrect or the use is unlawful.
  5. Right to Object: Objecting to use of your information (where a party is processing it on legitimate interest basis) and to have your personal information deleted.
  6. Right to Erasure: In certain circumstances, you may also have your personal information deleted.

 

The GDPR also defines roles and responsibilities of all parties in regards to collecting personal data. Data Controllers are the primary collectors of personal data from a data subject and have a responsibility to respond to any requests by a data subject to exercise their rights under GDPR. Data processor are anyone who process the information on behalf of the Data controller and they have to make sure their systems are secure and that data controllers can fulfill requests from data subjects in regards to controlling their personal data. So for example if Joe Blow asks to have all his personal data erased, that data needs to be erased from all storage in a timely manner, no excuse.

So there is onus on data controllers and data processors to protect your privacy, the goal being to ensure systems are developed with consumers privacy in mind or “Privacy by Desgin” principles.

These responsibilities translate to MantisHub and our service in the following way.

  • For information gathered on account owners and potential customers when offering our Issue tracking and Helpdesk services, MantisHub performs the role of data controller and are required to respond to any requests from account owners.
  • For information stored in customer MantisHub services (customer content) which may be personal data, the account owners are the data controllers and MantisHub is the data processor. This includes information like registered user details (real name, email address) or data collected and added to your MantisHub issues which can identify an individual. Account owners are responsible for responding to GDPR requests regarding this data and MantisHub must ensure they have the tools to fulfill these requests and making sure the data is secured.

 

In preparation for GDPR and to help our customers also become GDPR compliant, MantisHub have made a number of changes. We have:

  1. audited how Personal Data is processed by MantisHub and determined how it is stored, used and how long it is retained.
  2. ensured automatic deletion of customer content after 30 days from when your account subscription expires or is cancelled.
  3. updated both our Terms of Service and Privacy Policy to provide clarity and transparency on how we collect and use your data and better comply with the GDPR.
  4. produced GDPR compliance documentation on our website to advise how we protect your data and allow for our customers to become GDPR compliant. This includes a list of our 3rd party, GDPR compliant providers.
  5. provided a guide on how to exercise your GDPR rights.
  6. updated some of our security procedures and included information in our security FAQs documentation.

 

MantisHub is proud to continue offering a secure, reliable service to our many EU customers as well as those throughout the world. We take customer privacy very seriously. We never sell or share your data and only use it to provide you with the best possible service. So be at ease :).

Thank you for being a part of the MantisHub community! We’re here for you so if you have any questions about GDPR or other, don’t hesitate to reach out to our team!

 

 

Keep your users in the know with MantisHub’s Announcement Plugin

Announcements Plugin Image2

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.

AnnouncementsPlugin_04

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…

Get Closure with MantisHub – Issue Lifecycle and Workflow.

ClosureTitleImage_02

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.

changestatus

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.

  1. 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
  2. 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.
  3. 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.

 

Workflow transitions

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.

workflow_trans_change

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.

ACLtransition_markup

Helpdesk workflow

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 :).