Best practices for setting up Groups (types and number of groups)

Christel Gray

Hi Everyone,

We are in the process of refining our Groups in Jira admin and I've been researching online best practices, but have had no luck finding what I need. I'm hoping the Atlassian Community can help.

The reason we are refining our Groups is because we are wanting to open up Jira projects to visible to more people in our organization while at the same time limiting some visibility for some projects (through using schemes).

We have some people who want to set-up the groups similar to below:

* Role

* Role - Country

* Role - Country - State

* Role - Country - State - City

or

* Department

* Department - Country

* Department - Country - State

* Department - Country - State - City

So most people will be in five groups (default is jira-users) and we'd have to have permission schemes to accommodate the different role/department, country, state, and city of each group. That in itself gives me a headache.

The argument for doing this is that they feel people in some areas should have access to projects in only those areas. But of course, our projects span many geographic areas (we have almost 30 locations in 15 countries). 

What I'm interested in is how other organizations have set-up their groups and if there are any best practices resources. 

Thank you!

Chris Boyd_vgrzlm

Christel, 

 

The community here may share with you best practices from their perspective, but I'd like to share you my thoughts from the Jira side of things.  It appears what you're trying to accomplish is this (forgive me if this oversimplifying):

• Limit project permissions based on the user's geographic location

From your given scenario, indeed the headache would come from the sheer scale of admin work needed to manage all the project permission schemes for all the potential groups you'd have to come up with!

To help come up with a better plan, consider the following from the Jira docs (again, please forgive the simplification):

• Groups are for organizing users together who should have the same permissions.
• Project roles are for associating a project function (example: editing an issue) to a user or group of users.
• Permission schemes are used so you only have to match these groups to their project roles once.  After that, you can apply the permission scheme to multiple projects.

So my recommendation as you plan this out, consider an approach of top down from project down to users:

• In the permission scheme, match the role to the permission, not the group.
• Apply this permission scheme to all the projects you need it on.
• Associate the appropriate groups to the roles.

In that way, all the work left is putting the users in the correct groups, and going forward when users come and go, all you have to do is manage which users are in which group.

Again, this is very oversimplified, if the problem is too complex you may want to wait for the community to chime in, or perhaps seek out a consultant.

Good luck!