Jira Project Roles - Users -vs- Groups - Both performance and management

[Daniel Ciarlette]

As we grow our users we are debating on managing users in projects.  Our Jira is v7.5.2 and we use Crowd but no Active Directory integration.   Some people say that we should put users in groups and add groups to Project roles.  Others feel that we should just put users in the roles. 

I see both ways.  Some claim groups in roles gives better performance but I can't find anything that states this.  Others suggest putting users in roles because then the project admins can add/delete their own users - thus reducing our administrative burden.

We have about 950 users in 200 projects.  No project has more than about 40 users per project.

I look forward to your comments.  Thanks,

Dan

[Nic Brough -Adaptavist- · Accepted solution]

For large user bases, users in roles can be measured as faster.  But it's not a great improvement, and not a reason to prefer them. (The main load is the permissions checks in there if you wanted to know)

Roles however, let you delegate ownership to project admins.  Rather than explain it, I'll give you a real-world example.

Years ago, I worked for a very large multi-national.  Tens of thousands of users.  When I started, there were 8 admins struggling to get any real work done because they were constantly having to move people around in groups.  My second job there was to find a way to streamline this to free up the admins a bit.  I converted one third of the projects to use roles instead, and the admins who looked after those projects suddenly had all their time free to do real work.  (The other option I suggested was to use groups properly - external user directory which is maintained by HR, not your Atlassian admins)

[Daniel Ciarlette]

@Nic Brough -Adaptavist-  What you mention seems to fit my use case because my organization is more like a consortium of research projects from different organizations.  So we don't have an HR department or Active Directory to manage groups from.

The delegation to the project admins is the thing that seems enticing to me because I don't have to manage the project roles population of users then.  We just need to make sure people have accounts and keep the software running.....

I currently gather the list of people that have a role in the project and create a group based on the project key that we use for Confluence access for the project's space.  But, that is the only place we use the group.   That works great.

[Brittany Wispell · Accepted solution]

Hey @Daniel Ciarlette

This is a great question! I am actually creating a blog post about this! 

Based on best practices you'll want to add users to a group then add the group to the roles within each project. This is much cleaner and as people are deactivated you won't have to worry about the mess of deactivated people in the project roles.

You can easily remove them from the groups which keeps the projects clean and you can search on what group is within each project. 

Now if you only have 1-5 individuals that needs to be in the project role and don't fit into a specific group then this is when you would put the individuals within each project. 

I hope this helps! I will look for some documentation on this. But within my company we use this rule on implementing groups and roles in projects for our customers. 

Have a great weekend!

[Daniel Ciarlette]

Brittany, you have given me great information twice in two days.  Awesome!

For us, the groups and projects are a 1-1 relationship.  So, removing from a group or removing from the project is about the same effort.  It just seems the group is just adding one more level of indirection. 

We are probably odd in that almost no group will ever span multiple projects like may happen in a normal company.  Think of every Jira project like a separate company. We are a collection of independent high performance computing projects from all over the country.

There are times were an individual user may span a few projects and I was trying to determine if it was better for a Project Lead to be able to add them and that is no load on the Jira administrator then.  Also, it is harder for the Project Lead to see who is on their project if there are only groups listed in the roles since Jira (without yet another addon) will not allow a Project Lead or Administrator to click on the group to see the membership).

Thanks for your input,

Dan

[Brittany Wispell]

I'm glad I could help @Daniel Ciarlette! Looks like your company needs a separate approach away from best practices which if it works for your company then why change! That's the beauty of Jira, being able to have a way to specify the tool to fit your needs. :) 

There are only a couple instances where something is really being done THE WRONG way but as long as your team is getting the proper reporting and your team is working efficiently then there is no reason to alter the existing state. 

Hope to help you more in the future! Have a great weekend.

[Pedro Felgueiras · Accepted solution]

Hi @Daniel Ciarlette

Besides the performing aspect users or groups should be used with the context in mind. 

For us, when a hole group should have access to a permission the group is added, when is a need for a specific user to have some permissions the user is added. 

It's more simple to manage the permission by groups (when the group name have a meaning) then by user. 

My advice is to use groups when you can and use users when you need. Worst then a small performance degradation is a big management issue. 

Best regards, 

Pedro Felgueiras

[Daniel Ciarlette]

Thanks everyone for your input.