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:

 

19 comments

Jimi Wikman
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.
January 25, 2022

Looks great Jimmy!

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

Like # people like this
Nikki Zavadska _Appfire_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 25, 2022

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
Matt Doar
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 25, 2022

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 25, 2022

Thank you everyone!

@Matt Doar 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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 25, 2022

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

Like Jimmy Seddon likes this
Dave Keating January 26, 2022

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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
Sussi Åström June 21, 2022

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
Jenny Severin July 12, 2022

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 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!

Dib Oglesby September 7, 2023

Jimmy, as per your post on 7/13/22:

 

In creating the Contractor Project Role, did you have to remove 'All Logged In Users' from the default permissions scheme Browse Projects permission?  As of now I'm looking at using Internal and External groups, and Internal and External permission schemes, but I'd prefer the Project Role version of this.

 

Thanks!

Like Jimmy Seddon likes this
Jimmy Seddon
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 8, 2023

Hi @Dib Oglesby,

Yes, anytime I have been involved in setting up permissions that involve people from outside the organization (which is most of the time).  We never use "All Logged In Users" since they are given a domain sync'd account to perform their work.

I prefer the "Contractor" project role vs an Internal Group as it gives you more flexibility to add different sets of contractors to different Jira projects which share a common permission scheme.

I hope that helps!

Dib Oglesby September 8, 2023

@Jimmy Seddon Thanks for that.  I'm still working thru it at the moment, trying to get the best solution.  

Like Jimmy Seddon likes this
Dib Oglesby September 8, 2023

@Jimmy Seddon Ok, so here is the question: Say I have an external permission scheme, and 3 external projects that use that scheme.  I've got an external user who I want to be able to do anything in one of those projects, but only be able to view the other two.  Using project roles, do I have to specifically add him to all of the projects, and assign a project role for each?  What we are looking to do is let external users view all the external project, but only interact with specific ones.  Can this be done using project roles easily, or is that a place to use groups?  

 

Thanks in advance

Jimmy Seddon
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 8, 2023

Ok, interesting use case.  From what I have usually dealt with.  Contractors have more than just view permissions, but they are only allowed to see the individual project they are working on.  This is why roles are great.  You can define view/create/edit access and then on a per project basis, add the specific contractor group to the Contractor role and they will get all the permissions they need, but only for that project.

In your case it looks like you are less concerned with view access.  I would consider having a "View Only" role when you can give that to all contractor groups per project (or you could simply add the groups to the browse project permission in the permission scheme).

Then, use the contractor role for all interaction permissions where on a per project basis you can limit which contractors have the ability to interact with that project by the Contractor role.

I hope that both makes sense and helps you achieve what you are trying to accomplish.

Dib Oglesby September 8, 2023

@Jimmy Seddon That's what we were thinking, create an External Users group and give them Browse Project permission is the scheme, and then use other (Possibly existing) roles for interaction within specific project.  

 

Now here is a different question, but I think I know the answer: is there a way to exclude a group from permissions?  In the case above, for our internal projects, can we say 'don't allow the external group to have Browse Project permissions for projects using the internal permission scheme'? I don't see anything like that in there.

Like Jimmy Seddon likes this
Jimmy Seddon
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 8, 2023

What you have listed looks like a good plan.  And yes you are correct, there is no way to define a "deny" list of groups, but I agree that would be helpful.

Dib Oglesby September 8, 2023

@Jimmy Seddon appreciate all the help today!  have a good weekend

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events