I have been experiment with permissions schemes and project roles to help control access to projects on my Jira Cloud instance. My question is, does Jira supports some sort of "permission nesting" (or is there an official way to emulate such behavior). For example, suppose I have the following 3 roles: * Viewer - Can only see a project and it's issue * Developer - Viewer + Can create and edit issues * Administrator - Developer + Full control of project In the permissions scheme, to implement Viewer, for example, I would grant the "Browse Projects" permission to the "Viewer" role. However, does this mean I would need to explicitly grant the "Browse Projects" permission to the "Developer" and "Administrator" roles as well to implement my desired permission "nesting"? Or is there a better way?

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; } } }

Nested Role-Based Permissions

Patrick Wright

I have been experiment with permissions schemes and project roles to help control access to projects on my Jira Cloud instance. My question is, does Jira supports some sort of "permission nesting" (or is there an official way to emulate such behavior).

For example, suppose I have the following 3 roles:

Viewer - Can only see a project and it's issue
Developer - Viewer + Can create and edit issues
Administrator - Developer + Full control of project

In the permissions scheme, to implement Viewer, for example, I would grant the "Browse Projects" permission to the "Viewer" role.

However, does this mean I would need to explicitly grant the "Browse Projects" permission to the "Developer" and "Administrator" roles as well to implement my desired permission "nesting"? Or is there a better way?

Accepted answers

Marc -Devoteam-

Hi @Patrick Wright

That depends.

You could grant browse permission to the viewer role and let's say edit permission to the developer role.

This would require you to provide a user that needs edit permissions to be granted both roles.

If you would grant browse permission to both roles and edit permission only to the developer role, you would only need to grant a user that needs to edit issues the developer role and not also the viewer role

Best practice is the second option.

This requires you to grant people a single role, instead of multiple roles.

All comments

Marc -Devoteam-

Hi @Patrick Wright

That depends.

You could grant browse permission to the viewer role and let's say edit permission to the developer role.

This would require you to provide a user that needs edit permissions to be granted both roles.

Best practice is the second option.

This requires you to grant people a single role, instead of multiple roles.

Dave Mathijs

Hi @Patrick Wright

The Browse Projects permission is a so-called "standalone permission" and a pre-requisite for almost any other permission in a permission scheme. It controls who has access to a project, and consequently who has access to individual issues in that project.

It’s incredibly powerful; if you can't browse projects, you can't see issues. If you can’t see an issue, of course, you can’t edit, transition, comment or do anything with it.

Restricting the Browse Projects permission will influence what users will see on dashboards and in filters, and the email notifications that they receive.

This means that when you're configuring permission schemes or troubleshooting permissions, or the visibility or notifications from issues, you must always consider the Browse Project permission.

⚠️

The Browse Project permission may make project details visible to all users in directories and while searching Jira

There’s a known issue when granting a User custom field value, Reporter, Current assignee, or Group custom field value the Browse Project permission. In these cases, a project becomes visible to any logged in user on your Jira site.

Patrick Wright

It took a little effort to go through the permission scheme and grant permission explicitly for each role, but now that it's done, it's pretty simple and self-explanatory to see what permissions a user/group a granted (by role) for a given project.

I ended up with the following roles:

Viewer - Can only see a project and its issues
User - Viewer + Can add issues to the project
Developer - User + Can be assigned to issues and work on them
Product Owner - User + ...
Scrum Master - Developer + Can manage sprints, archive items, etc...
Administrator - Full access to project

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud