Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How do you manage permissions in Jira?

Chris Rainey
Community Champion
May 24, 2024

Hi everyone,

Hoping to get some configuration examples/ideas or just some general thoughts to take back and think through.

I have inherited a Jira site and it's clear that this site was configured with one team in mind. Since I've been the administrator, there have been many teams and departments that have joined the site so the configuration is no longer suitable for me as a project administrator. Not having standard configurations results in too much manual work for me to spin up a new project but I'm also noticing that it's leading to collaboration gaps because teams aren't always speaking the same language (as far as custom fields on different projects goes).

There are a few thoughts I have on configuration changes but the one I want to focus on is permission schemes. We have a few groups that are all relative to one team. I want to instead revamp those groups and use them as a better way to set a baseline level of access for new users in Jira. 

For anyone who handles Jira permissions via groups, in what way do you bucket your Jira users? I have considered going using organization (I work for an organization that contains several child organizations), department (these change too frequently for my liking and I know it's not currently possible to change a group name), and team. Do you have any suggestions? Any thoughts? Any pros and cons? Any other grouping buckets I should consider? Interested in any and all thoughts.

3 answers

2 accepted

0 votes
Answer accepted
Mohamed Riza _ServiceRocket_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 24, 2024

Hi @Chris Rainey 

You can look into grouping them on multiple factors. So, this could be organization-team-role format. Example: at-product-developers where 'at' is the shortform for the organization, Atlassian, 'product' refers to the product management team, and 'developers' is the role of the individual in the team. 

Ultimately what you decide on depends on what makes sense and is suitable for your organization. I would recommend looking at one type of project to see what makes sense and then see how this would work for all the other projects. 

This would definitely be a time intensive process but will pay off in the future. 

Hope that provides you with some guidance. 

0 votes
Answer accepted
Matt Parks
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 24, 2024

My general viewpoint is that everything in Jira should be open to all logged-in users unless there is a specific reason to lock things down. So I have a a single AD group that allows permission into Jira and a generic permission scheme that allows users in that group to browse the project.

If there are any specific projects that need to be locked down, I have different AD groups created and separate permission schemes that allow those groups to browse the project.

At least where I've used Jira, it's rare that there is a need to restrict access to certain areas of the tool once users are able to log into Jira.

Chris Rainey
Community Champion
May 24, 2024

I see. When you say open, what kind of permissions does that relate to? Right now, the three roles we have in use are Administrator, Project Editor, and Project Viewer. For your example in my situation, are you saying that all logged-in users would be Project Editors for all projects using the general permission scheme?

Matt Parks
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 24, 2024

We use a large number of shared schemes, so we don't really have project admins, since that would allow them to update a workflow or screens that are shared by other projects.

We are using DC so it's possible the naming convention is slightly different in Cloud, but we have a team of system administrators that manage everything from an administrative perspective, and then end users who can do pretty much everything else (e.g. create/manage sprints, any type of issue update, etc.)

There are some instances where particular groups of users can execute certain transitions, but we manage almost all of that via AD groups, which removes the responsibility of maintenance from the system administrators and puts it onto the Access Management team.

0 votes
Chris Rainey
Community Champion
May 24, 2024

I probably should have chosen a discussion rather than a question but ah well, I'll just accept responses as answers lol

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events