Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,466,414
Community Members
 
Community Events
176
Community Groups

Jimmy's Jira Permissions - Tips & Best Practices

I’ve had to restructure permissions a few times now and I thought it might be beneficial to share some of the things I have learned over the years and some of the things that I setup to reduce the amount of permissions maintenance I need to complete after completing these steps.

Creating project roles for use (Optional):

The first thing you will want to do is take a look at what project roles you have on your Jira instance (you can find these in the Admin section under the system menu). What roles you have listed will depend on your own Jira instance. You may want to add more roles to provide you with enough flexibility to create different sets of permissions to assign to users & groups.

Setting up permission schemes:

  • Try to setup the scheme with only project roles in it.
  • Create new roles as necessary to categorize permissions

  • Permission schemes can only be edited by Jira Admins so the more changes that can be delegated to project admins the betters.

Selecting the permissions for each project role:

I have two ways I have set this up in the past. I wouldn’t say one is better than the other, I have used both it depends on the members using the project and what makes the most sense for them to think about permissions:

  1. Additive permission roles:

    1. With this setup the project roles are a hierarchy and the higher level roles will contain all of the permissions that the lower tiers.

    2. When assigning project roles in this setup, you will only assign users/groups a single role, and you will change the role to upgrade/downgrade the permissions.

  2. Separate roles for different sets of permissions:

    1. With this setup you will assign users/groups as many roles as they require to get all the necessary permissions they require. Note: this setup should also make sure that the roles accurately describe the permissions they will provide

Assigning Users/Groups Project Roles:

  • In my opinion, try to use groups as much as possible over individual users
  • By using groups, If group membership is coming from a third party identity provider, changes to group members won’t require you to make any changes to project permissions to clean up users that shouldn’t have access anymore.

In Conclusion:

This is what I have used to setup project permissions, I would love to heard thoughts, opinions and best practices from others as well.

Also, If you are interested in watching my video version of this, you can find it on my YouTube channel:

 

11 comments

Looks great Jimmy!

Agree with the setup and I love that more Jira gurus start YouTube channels :)

Like # people like this

This is a great sumup @Jimmy Seddon  thank you for sharing!

We are usually using separate permissions per role but the additive approach is definitely interesting and worth trying!

Like Jimmy Seddon likes this

Sweet and brief, thanks!

"Try to setup the scheme with only project roles in it."

I agree, except I will often add the jira-administrators group to the Administer permission so that project admins cannot stop Jira administrators from administering their project.

"In my opinion, try to use groups as much as possible over individual users"

Yes, and a permission scheme with specific users is generally a Jira admin smell. 

 

Also, there is probably enough to discuss about when to create a new project role for its own post. And how to know when you can delete a project role entirely

Like # people like this
Bryan Trummer Community Leader Jan 25, 2022

This was a great overview. I really like the thoughts shared here and using project roles in schemes as much as possible.

Like Jimmy Seddon likes this
Jimmy Seddon Community Leader Jan 25, 2022

Thank you everyone!

@Matt Doar__ LinkedIn really good thought about adding the jira-administrators group to the scheme.  I'm going to remember that tip!

@Nikki Zavadska _Appfire_ the additive approach is something I discovered when a Project Admin asked why a user didn't automatically get all the permissions a "Viewers" had when being added to the "Members" role.  That's when I realized there are a few different ways to thing about permissions.

Andy Gladstone Community Leader Jan 25, 2022

Just finished watching the video @Jimmy Seddon - great job on the production and delivery!

Like Jimmy Seddon likes this

Thanks for the video @Jimmy Seddon - really helpful. I had one question for you - I have to have product access permissions, but then break permissions down to location, and then to clients.

From watching your video, I'm thinking I could set Global Permissions with groups that covers Admin, Team Leads and Users. Then set Jira project permissions for 'location' and 'client' using groups.

Would that be the most efficient way? It would keep the number of groups at a global level minimised, and I could give Team Leads the ability to add users into their client groups to allow access for people who join their team. But maybe I'm not thinking about this the right way?

Thanks again!

Like Jimmy Seddon likes this
Jimmy Seddon Community Leader Jan 27, 2022

Hi @Dave Keating!

Thanks for checking things out and for the question.  What you have suggested actually sounds like a really good plan!

-Jimmy

Like Dave Keating likes this

Thanks for the video @Jimmy Seddon - really helpful. I've watched it a few times, as making a plan of how permissions should be implemented in our company vs. how it's done now.

Cheers, =)Sussi

Like Jimmy Seddon likes this

I'm looking for best practices on group management for Contract employees.  We have multiple contract employees working in various projects and we only need these Contract employees to see projects that they were hired to support. I feel group management is still the best bet, but do you feel that I need to create a Contractor's group for each project?  That would require multiple permission schemes too, right?  Any tips on this would be helpful...Thank you. 

Like Jimmy Seddon likes this
Jimmy Seddon Community Leader Jul 13, 2022

Hi @Jenny Severin!

If your company acts the way mine have in the past, all contractors had the same set of permissions, we just wanted to make sure they only had access to the project(s) they were supposed to be looking at, and nothing else.

To accomplish this, we actually made a "Contractor" project role.  That allowed us to setup the correct permissions assigned in the permission scheme (including Browse Projects) to the Contractor role.  Then, in each project we would add the individual groups for each contractor company to the projects they were allowed to access.

I know this can and does have some admin overhead, but I don't think it's avoidable when you are trying to protect a large amount of your data from contract workers.

I hope that helps!

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events