While Jira is a powerful project management tool, it also has a potent ability to create confusion.
As an Atlassian expert, one of the most common sources of frustration is Jira’s multi-layered permission mechanism. By giving administrators two paths to assign access — project roles vs. user groups — it’s easy to overcomplicate the process of optimising Jira Permissions.
Let me explain with an example: A Jira instance is installed with both Jira Software and Jira Service Desk. While there are only a few Service Desk projects, there are 20 people who need portal access to all service desks. Technically speaking, those users must be assigned the project role “Service Desk Customers” for each of the Service Desk projects.
The administrator doesn’t want to manually assign those 20 users to the project role on each new project. Understandably, she wants this to happen automatically.
There are two ways to solve this problem, and I’ll let you be the judge of which works best.
Solution #1: The Brute-Force Way
Add those 20 users as default members of the project role “Service Desk Customers.”
That first step is not an issue for the Service Desk administrator. Cleaning up the mess, however, is a bigger deal for her fellow administrators in other departments. Because the “default members” option is implicated across the system, it also applies to the Jira Core and Jira Software projects.
Now, with each new Jira Software project, all administrators will be “greeted” at the outset with a ton of clutter: 20 extra lines in the project roles screen. There’s no bearing on or security issue with the users designated as “Service Desk Customers,” as it doesn’t grant them access. But for each administrator, it’s an overwhelming mess, which requires them to remove those users manually.
Solution #2: The Clean Way
To be a good colleague and ease the burden on administrators system-wide, all you have to do is create a new user group, and call it something like, “Default Service Desk Customers.”
Now, assign your default members to that user group, and make that user group the default member of the project role, “Service Desk Customers.” (Note: this is optional, as it’s now also only a single operation to add this group to the project role when you have an Service Desk project.)
And voilà! With each new project, there is now only one extra line (instead of 20) in the project roles list. It does not create clutter, and the project administrator can remove it with one click if desired. (There is also no harm if they leave it there, it has no impact).
Now you have your choice, permission to make your Jira experience simpler and more blissful is… granted!
Tags: jira, jirapermissions, jiraadministrators, jiratricks, simplejiratricks, jiraservicedesk, jirasoftware
Blog posts in this series:
- Agile for GXP and Medtech
- Why Jira’s Kanban Board is What Your QA Team Needs
- Prepare For Compliance Audits With the Newest eSignature App
- How Agile Teams Can Avoid Being Victims of Their Post-it Habits