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:
Additive permission roles:
With this setup the project roles are a hierarchy and the higher level roles will contain all of the permissions that the lower tiers.
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.
Separate roles for different sets of permissions:
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:
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.
"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
@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.
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 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.
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.
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.
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.
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.
@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?
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.
@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.
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.
Good thoughts and information. I do personally mostly disagree on the use of groups over users in role assignment.
I think groups do work in the case where you are at the final stage and have the group membership determined by your Identity Provider, we're definitely not there currently.
I absolutely want to use groups, but the following are deal breakers for me:
Group membership is only visible to User Admins and above
Group membership is only editable by User Admins and above and in some cases User Admins cannot edit the membership of a group provides certain levels of elevated access
I feel like it totally makes sense to have Project Administrators manage who has access to their project and in what capacity, but with Groups being opaque to Project Administrators, if we assigned roles on that basis they would actually have no capacity to see who has access to their project.
If the Identity Provider generates the group membership, that's further obfuscated, but at that point you're hopefully sufficiently organized that this doesn't represent an actual problem.
With where we are, we depend on the Project Admins to do regular audits of their project members and they can't do that if we hide the membership through groups, generating additional overhead for us to tell them the group membership for their auditing.
20 comments