3.1 Permission Scheme Mechanics & Critical Project Permissions

Permission Scheme Architecture & Critical Project Permissions

In Jira Cloud, access control for company-managed projects is governed by Permission Schemes. A permission scheme is a centralized, reusable matrix that maps individual project-level permissions to specific entities—such as project roles, user groups, and dynamic issue actors. Understanding how permission schemes function, how grants are evaluated, and the precise boundaries of project administration is critical for managing enterprise Jira Cloud sites and succeeding on the ACP-120 exam.

---

Company-Managed vs. Team-Managed Permission Models

Before exploring permission schemes, it is vital to distinguish between Jira's two project architectures:

• Company-Managed Projects: Use shared configuration schemes (permission schemes, issue type schemes, workflow schemes, screen schemes). Access control is centralized and standardized across the Jira site, managed by Jira Administrators with delegated membership control given to Project Administrators through Project Roles.
• Team-Managed Projects: Do not use permission schemes. Instead, they use self-contained, project-specific access levels (Open, Limited, Private) with localized roles (Administrator, Member, Viewer) managed completely inside the individual project settings.

The remainder of this chapter focuses on company-managed projects, where permission schemes and issue security schemes operate.

---

The Architecture of Permission Schemes

A permission scheme consists of approximately 40 distinct permissions categorized into logical functional groups. A single permission scheme can be associated with multiple company-managed projects. When an administrator modifies a shared permission scheme, the changes immediately apply to every project associated with that scheme.

+-------------------------------------------------------------+
|                   Shared Permission Scheme                  |
|  - Browse Projects    --> Project Role: Service Desk Team   |
|  - Create Issues      --> Group: jira-software-users        |
|  - Edit Issues        --> Project Role: Developers          |
|  - Administer Projects --> Project Role: Administrators     |
+-------------------------------------------------------------+
         |                                     |
         v                                     v
+-------------------+                 +-------------------+
|  Project Alpha    |                 |   Project Beta    |
|  (Role Members A) |                 |  (Role Members B) |
+-------------------+                 +-------------------+

Permitted Entity Grant Types

Jira lets you grant each permission in a scheme to several kinds of entity:

---

Core Permission Categories & Critical Permissions

Jira organizes permissions into six primary categories. Administrators must master the exact behavior and administrative implications of each.

1. Project Permissions

• Browse Projects: The single most critical permission in Jira. It determines whether a user can see the project, view its issues in search results, view agile boards, open project pages, or receive project notifications. If a user lacks Browse Projects, the project effectively does not exist for them (navigating directly to an issue URL returns an error indicating the issue does not exist or access is denied).
• Administer Projects: Grants delegated administration of the project. It allows managing components, versions, project role memberships, and localized settings.

2. Issue Permissions

• Create Issues: Governs whether a user can open the global Create modal and create new issues within this specific project.
• Edit Issues: Allows modifying field values on existing issues (via the Edit dialog or inline editing on the issue view).
• Assign Issues: Governs whether a user can perform the act of assigning an issue (changing the value in the Assignee field).
• Assignable User: Governs whether a user's name can be selected as an assignee.
• Close Issues: Allows transitioning issues into a status in the "Done" category where the transition is guarded by closure permissions.
• Resolve Issues: Allows resolving and reopening issues, including setting the Fix Version/s field.
• Schedule Issues: Governs the ability to populate and edit the Due Date field and drag issues across timelines/roadmaps.
• Delete Issues: Allows permanently deleting issues from the database. In enterprise environments, this permission should be strictly restricted to Jira Administrators or removed entirely, replacing deletion with an "Archived" or "Cancelled" workflow status.
• Move Issues: Governs moving issues between projects (or between workflows in the same project). To move an issue into another project, the user also needs Create Issues in the destination project.
• Modify Reporter: Allows changing the user recorded in the Reporter field.
• Set Issue Security: Governs whether a user can view and change the Security Level field on issues when an Issue Security Scheme is applied.

3. Comments, Attachments & Time Tracking

• Comments: Includes Add Comments, Edit All Comments, Edit Own Comments, Delete All Comments, and Delete Own Comments.
• Attachments: Includes Create Attachments, Delete All Attachments, and Delete Own Attachments.
• Time Tracking: Includes Work On Issues (logging work against an issue), Log Work for Others, Edit Own Worklogs, Edit All Worklogs, Delete Own Worklogs, and Delete All Worklogs.

4. Voters & Watchers

• View Voters and Watchers: Allows seeing the list of users voting for or watching an issue.
• Manage Watchers: Allows adding or removing other users to/from the watchers list of an issue.

---

The Critical Interplay: Assign Issues vs. Assignable User

A frequent stumbling block on the ACP-120 exam is the operational distinction between Assign Issues and Assignable User:

+------------------------------------+       +------------------------------------+
|            Assign Issues           |       |           Assignable User          |
|   The *Actor* performing the act   | ----> |  The *Target* receiving the work   |
| "Can I change the Assignee field?" |       | "Can my name appear in the list?"  |
+------------------------------------+       +------------------------------------+

Consider the operational matrix:

• User has Assign Issues, but NOT Assignable User: The user (e.g., a Project Manager or Scrum Master) can reassign issues to developers, but they cannot assign an issue to themselves, nor can any other user assign an issue to them.
• User has Assignable User, but NOT Assign Issues: The user (e.g., a Junior Developer or External Contractor) can be assigned tickets by team leads, but they cannot reassign tickets to other team members or even unassign themselves.
• User lacks both: The user cannot change assignments and cannot receive assignments.

Exam Trap: Remember that to be an Assignable User, a user must also possess the Browse Projects permission. If an administrator adds a user to a group granted Assignable User but omits Browse Projects, the user will never appear in the assignee dropdown menu.

Specific Permissions Beat General Ones

Atlassian documents that when two permissions overlap, the more specific permission decides. Edit Issues normally lets a user change any field, including Assignee. Once you configure Assign Issues in the scheme:

• only users with Assign Issues can change the Assignee field;
• users with only Edit Issues can change every other field, but not Assignee;
• users with Assign Issues but not Edit Issues can change only the Assignee field.

---

Delegated Project Administration: Boundaries & Cloud Guardrails

The Administer Projects permission delegates significant autonomy to project leads and managers without granting full Jira Administrator rights. However, clear boundaries exist between what a Project Administrator can do versus what requires a global Jira Administrator.

Edit Workflows and Manage Work Item Layouts

Jira Cloud has replaced the old Extended project administration permission with two narrower project permissions, both granted in the permission scheme and both requiring Browse Projects:

1. Edit workflows: Lets the holder update statuses and transitions in the project's workflow using the workflow editor, but only if no other project uses that workflow.
2. Manage work item layouts: Lets the holder change which existing fields appear on the project's issue layout, but only if the layout's screens aren't shared with other projects. It doesn't allow creating new custom fields.

If the workflow or screens are shared, the change needs the Administer Jira global permission. To delegate workflow changes to one team, a Jira admin can copy the shared workflow, map the copy to that project's workflow scheme, and then grant Edit workflows in the project's permission scheme.

A separate Manage versions (releases) permission lets users create, release, archive, merge, edit, and delete versions without full project administration.