JIRA Permissions General Overview

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.

Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

JIRA has a flexible security system that allows you to configure who can access JIRA, and what they can do/see within JIRA:

  1. Global permissions - apply to JIRA as a whole (all existing projects within your instance).
  2. Project permissions - organized into permission schemes, these apply to projects as a whole (e.g. who can see the project's issues ('Browse' permission), create, edit and assign them).
    1. Comment visibility - allows the visibility of individual comments (within an issue) to be restricted.
    2. Work logs visibility - allows the visibility of individual work-log entries (within an issue) to be restricted. Does not restrict the visibility of the progress bar on issue time tracking.
  3. Issue-level Security - organized into security schemes, these allow the visibility of individual issues to be adjusted, within the bounds of the project's permissions.

Different Projects, Different Permissions

Permission schemes allow you to apply varying access levels to combinations of groups, roles, and individuals on a per-project basis. A permission scheme will enable/disable specific actions for users for that project. For example, the 'Browse Project' permission for a particular project restricts who can view the project in JIRA and thus view issues that belong to that project via the Issue Navigator. Without this permission, the user(s) would not be able to access ('browse') that project.

You could have permission schemes applied per project that give certain customer groups or roles access only to the project (via the 'Browse Project' permission) that pertains to them while giving the internal groups or roles all permissions across multiple projects. See Managing Project Permissions for further details.

Reusable Permission Schemes: Using Project Roles (default and recommended)

Each project has Project Roles associated with it: Project Lead, Administrators, Developers, and Users. As you define your Permission Scheme, you can assign permissions in your Permission Scheme to a Project Role (e.g. Project Role (Users)). When you select the Permission Scheme for a project, JIRA will grant the permissions specified in the scheme to the specific users/groups that you've defined in the Project Roles for your project.

This allows you to reuse the same Permission Scheme for different projects that have the same security needs, but different groups. You then select the same Permission Scheme for the Project but Manage Project Role Membership to substitute different users/groups. Sharing a Permission Scheme also facilitates the creation of Administrator groups across the projects.

Note: Jira does not support field-level permissions


Last modified on Nov 12, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.