Permission scheme Jira Premium

[BenWade]

Hi everyone, 

I am trying to set up permission scheme in Jira. I am watching this video(Alex ortiz) right now.

I found his approach confusing and wrong. 

He suggests:
create groups->assign people to groups->create roles->assign groups to roles->grant permissions to roles. It does not make sense for me. this approach just overcomplicates the whole process. creating roles should be skipped as it is pointless for me.

What I think is the correct approach: Create groups->assign people to group->grant permissions to groups. Am I correct or I am missing smth?

[Marc Koppelaar · Accepted solution]

Hi @BenWade 

The most useful hierarchy is Roles -> Groups -> Users.

Roles in a permission scheme allow project admins to grant groups or user a role in a project, no administrator needs to be involved. This can be done via the People section n the project settings

Groups or Users set in a permission scheme, will make the the people section in the project obsolete and any access granting to a project needs to be done by a site-admin

[Dave Mathijs · Accepted solution]

Hi @BenWade I understand the confusion.

Best practice is to use project roles over groups for more flexibility.

• When you grant a permission to a group, it is valid for all projects associated with that permission scheme.
  • The advantage is that group membership can be done via Active Directory (only when Atlassian Cloud is connected to an identity provider via Atlassian Access)
  • The disadvantage is that you need to be a Site Admin to manage group membership via Atlassian Administration directly.
• On the other hand, when you grant a permission to a project role, you can grant permissions to users/groups by adding them to the project role. This is done per project.
  • The advantage is that the Project Administrator can manage access to their project themselves.
  • The disadvantage is that Project Administrators need to be well aware of this and that you have no control over this as a Site Admin.
• The confusion comes from the fact that you can also add groups to project roles.
• To make things even more complex, you can add default members to project roles as well. These can be users or groups.

[BenWade]

I am a site admin, I have a full control over everything. We have a small team and I help my team with any Jira-related questions.

So can we conclude that I should just ignore groups? I should create roles, assign users to roles and then in the permission scheme grant permissions to different roles?.
is this the best practice? So basically groups are pointless for setting up permission levels?

[Dave Mathijs]

Groups are not pointless (if the permission should apply to all associated projects by default), but in other cases, project roles are preferred. They relieve your work as site admin because you can delegate project access and permissions to your project admin(s).

[Marc Koppelaar]

Hi Ben,

No that is not what I and @Dave Mathijs are saying.

It all depends on how you want to structure your Jira.

If you need to have a group of users, let's say as an example systems users that are used for connection to dev systems to have access all the time, I would at these users in a group and set this group to the required permissions in the scheme

As if you would assign these users or the group just a role on the project, anyone with the project admin role could remove the users or group. or change their role.

[BenWade]

@Marc Koppelaar @Dave Mathijs Now I got it. Thank you for your help guys.

[Flow Ace]

I understand that setting up permission schemes in Jira can sometimes be a bit confusing, and different approaches may work based on specific use cases. In the video by Alex Ortiz, he suggests a method involving groups, roles, and permissions, while you find it overcomplicated and prefer a simpler approach.

Your proposed approach of creating groups, assigning people to groups, and then directly granting permissions to groups is indeed a valid and straightforward way to manage permissions in Jira. It simplifies the process by directly associating permissions with groups, avoiding the intermediate step of creating roles.

Jira's flexibility allows users to choose the method that best suits their team's structure and workflow. If your approach aligns with your team's needs and makes the process more understandable for you, there's nothing inherently wrong with bypassing roles.

It's important to note that the effectiveness of your approach also depends on the size and complexity of your Jira instance and the specific requirements of your team. If you find that your method meets your needs and is more intuitive, you're on the right track.

Ultimately, Jira provides different options for managing permissions, and the best approach is the one that aligns with your team's workflow and is easy to maintain.