This is part of a blog series with our own tips on configuring your JIRA, maximizing your use of JIRA’s many features, and tailoring the platform to best suit your organization’s needs.
In recent years, JIRA has become the leading bug tracking, issue tracking, and project management tool, and is used by 70 percent of Fortune 100 companies. The software offers a variety of innovative and flexible features, which allow users to get the best out of the platform.
When our consulting team at Tempo works with customers on how best to set up their JIRA instance, one of the primary features we discuss are setting up project roles in JIRA. Project roles can be used in a flexible way to associate users and/or groups with a particular project. But they also gives admins greater control over who can access what information within JIRA, which is extremely important for most organizations. Unfortunately, from our experience, many organizations do not take advantage of this flexibility.
Within JIRA, all users are assigned to one or more project roles, depending on how much access to data a particular user is granted. The default roles in JIRA are:
-
Administrators (people who administer a given project).
-
Developers (people who work on issues in a given project).
-
Users (people who log issues on a given project).
Although JIRA was originally designed for developers, the platform has evolved through the years, and organizations are using it for a variety of additional uses, such as human resources, Agile marketing and sales, customer support, legal, finance, accounting, and more. This typically means that organizations require additional roles to be established in JIRA to distinguish the various purposes for which the platform is to be used.
As a JIRA admin, you’ll likely need to create new project roles in addition to the three above, or edit these default roles. For instance, organizations using JIRA for customer service purposes (such as a Help Desk) might, for example, find it confusing to simply use the default Project Roles (Administrator, Developer, Users). In this scenario, a beneficial way to maximize JIRA’s flexibility is to rename the Project Roles with descriptive names. For example, a finance company might want to rename the Project Role “Developers” to Managers instead, and “Administrators” to Executives. Some companies might even want to add a new Project Role for their clients to enable them to view JIRA issues being worked on, and even to allow them to create new issues, if needed.
In JIRA, you can create, edit, and delete project roles according to your organization’s requirements. Atlassian’s documentation pages walk you through the steps of setting up and managing your project roles.
When creating a new project role it’s good to keep the following things in mind:
-
What tasks does a user with a specific role need to be able to perform?
-
Does the user need any additional access rights, and if so, does he or she require a new project role?
-
Are the roles that have already been established adequate enough for all projects in JIRA?
Groups or individuals are associated into each role depending on the project. It’s best to use groups to allow for easier control of user access. Therefore, you can remove a user from a group in order to shut down access to certain projects.
All users with access to JIRA must be assigned to a default JIRA user group, and therefore, we advise not to use that default group in any of the permissions schemes. This is done to prevent all users from having browsing privileges to access all data within JIRA.
JIRA’s roles also carry over to Tempo’s add-ons. Tempo’s flexible permissions schemes allow Tempo admins to assign various permissions to JIRA users and groups, so the more tailored the JIRA role, the more guidance offered to the Tempo admin in determining permissions to access data and utilize specific features in Tempo.
There you have it! Make sure you keep these things in mind when managing project roles to get the best out of JIRA and Tempo. Stay tuned for more JIRA tips from us!
