nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Groups and Roles, what is the solution for our organization ?

Bernard Van Heuverswyn

Hello All,

Since its creation our organization (NGO) used Trello to manage its projects (Work Management).

But we grew up and decided to opt for Jira - Work Management. We are currently about fifty people, distributed and 7 teams.

We can summarize our organization as follows: 6 teams each managing a specific project, and an HR team managing 2 projects (Onboarding & Employee monitoring).
We plan to start with Jira in 2 weeks, and I'm trying to define the basic parameters as well as possible. For this, I bought the book "Jira Work Management Basics" (Rynder Roy Klomp) which has already helped me a lot.
However, I'm a bit lost in setting up Groups and Roles (and changing the default values). For these 8 projects, I would have liked to use only the groups. Unfortunately, the HR project "Employee tracking" should only be accessible to a few specific users. Which seems to prevent me from working with groups because they give access to all projects.

What we should have as configuration:

ALL users must have access to ALL projects (6 teams + 1 HR) EXCEPT the HR project "Employee monitoring"
5 users must have access to ALL projects (including HR "Employee monitoring"
7 users (must be able to create new new projects): the project managers of the 6 teams + the HR Project Manager
Only the HR Project Manager can manage the 2 HR Projects. Remember, he can also manage the other projects

I feel like with the right roles and groups it's quite easily achievable, but I lack the experience. And also should we change the default Persimmsions (Global? Project)?

Can you advise me ?

Thanks

Accepted answers

Alex Koxaras -Relational-

Hi @Bernard Van Heuverswyn and welcome to the community,

You will work with groups for granting product access to those who have to have access to jira.

Create a few groups, without product access, which will be used with the project roles.

Create the project roles based on what each user should do on the projects. Try to find similar permissions, in order to minimize the project roles.

Grant the project roles to groups or individual based on your requirements.

All comments

Alex Koxaras -Relational-

Hi @Bernard Van Heuverswyn and welcome to the community,

You will work with groups for granting product access to those who have to have access to jira.

Create a few groups, without product access, which will be used with the project roles.

Create the project roles based on what each user should do on the projects. Try to find similar permissions, in order to minimize the project roles.

Grant the project roles to groups or individual based on your requirements.

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

The general rule here is "use groups to define what we instinctively understand as groups of people, using them for product access and reporting, but NOT project access" and "use roles to define who can do what in a project"

In your case, I would do this as a minimum:

Group: Jira-product-access. Put everyone who should be able to log into Jira into this, and make sure it's never used for anything other than the global setting for "can log into Jira".
- You probably already have this set up correctly, apart from; never use it in permissions, workflows, reporting, etc. It really should be limited to "can log in". (When you do need to use the group for something, use the "any user who can log in" options instead)
Group: General-developer. Put everyone into this group too, for now. You may find more cases where you don't want everyone in it in the future.
Group: HR. Only put your HR people in here
Group: Jira admins. Only put your admins in here
Global role: Developer
Global role: Project Admin

Now, set up a permission scheme that defines which roles get what access. I won't rattle through all the other 27ish permissions, the important ones are to set up:

Browse project: Role (Developer)
Administrate project: Role (Project Admin)

Do not use groups or individuals in your permission schemes; it gets far too complex to look after. Stick with roles.

In HR projects, add your HR group to the Developer role
In the other projects, add your General-developer group to the Developer role
In both project types, name the project admin(s) in the Project Admin role, including the HR manager

Now all you have to do is maintain the groups appropriately, and not think again about your projects!

There is one caveat in here. To create projects in Jira (Server/DC), you have to be a Jira admin.

Do not make your project managers Jira admins. They will be able to undo everything you set up, grant themselves and others access to the HR project, and generally break anything.

You should set up a small admin team (3 people in your case - a proper admin, your HR manager, and a third backup. HR and backup need some basic training in how to create projects and not break everything before you give them access). There's a little overhead for them in that your people who want new projects will have to go through them to get a new project, but you can pretty much create a "runbook" for that (what type of project, share schemes with existing project, add the requestor as a project admin, done. The project admin can add groups and people to roles as they see fit, so you don't have to even think about access)

Bernard Van Heuverswyn

@Alex Koxaras -Relational- Simple and very interesting.

Great

Thanks a lot Alex, This will be implemented today.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-core

group

role