3.2 Permission Troubleshooting, Additive Permissions & Permission Helper

Permission Troubleshooting, Additive Permissions & Permission Helper

Troubleshooting access and authorization problems in Jira Cloud is one of the most heavily tested domains on the ACP-120 exam. Administrators frequently encounter scenarios where a user unexpectedly has access to an issue they shouldn't see, or is blocked from performing an action they believe their role permits. Understanding how Jira computes effective permissions, how competing configuration layers interact, and how to wield diagnostic tools like the Permission Helper is essential for maintaining enterprise security.

---

The Additive Nature of Jira Permissions

The fundamental rule governing Jira Cloud authorization is that permissions are strictly additive. Jira evaluates permissions using a logical OR across all groups, project roles, and dynamic actors to which a user belongs.

Effective Permission = (In Group A WITH Grant) OR 
                       (In Project Role B WITH Grant) OR 
                       (Is Reporter WITH Grant) OR 
                       (Is Assignee WITH Grant)

The Absence of an Explicit "Deny"

Unlike file system access control lists (NTFS/POSIX) or certain cloud identity systems (such as AWS IAM explicit denies), Jira permission schemes do not support explicit 'Deny' rules. You cannot configure a permission scheme to say: "Grant Edit Issues to Group Developers, but DENY Edit Issues to Contractor Bob."

If Contractor Bob is a member of the Developers project role (which has Edit Issues), and also a member of the Contractors group (which does not have Edit Issues), Bob can edit issues. The absence of a grant in the Contractors group does not restrict or override the affirmative grant from the Developers role.

How to Restrict a User in an Additive Model

Because permissions cannot be explicitly denied, restricting a user requires one of the following architectural strategies:

1. Membership Pruning: Remove the user from the specific project role or group that conveys the grant.
2. Role Granularity: Split a broad role (e.g., Developers) into narrower roles (e.g., Core Developers with edit permissions, and External Contributors with view and comment permissions only).
3. Issue Security Schemes: Apply an Issue Security Level to restrict ticket visibility to specific actors, overriding project-wide permissions.
4. Workflow Conditions: Restrict transitions to specific roles or the current assignee.
5. Workflow Properties: Lock down issues in specific statuses using workflow metadata.

---

Troubleshooting Common User Permission Failures

When a user reports an authorization failure, experienced Jira administrators evaluate three classic root-cause patterns.

Pattern 1: User Cannot See a Project or Its Issues

When a user cannot find a project in the "Projects" dropdown, cannot view issues via direct URL, or finds that search returns no results, evaluate the access chain in this exact sequence:

1. App Access: Does the user have Jira app access in Atlassian Administration? Without it, they can't use Jira as a licensed user. (Browse Projects itself can be granted to site users without app access, which is how projects are shared broadly or publicly.)
2. Browse Projects Permission: Does the user belong to a group, project role, or dynamic entity granted Browse Projects in that project's permission scheme? Without Browse Projects, the project is invisible.
3. Issue Security Level: If the user can see some issues in the project but not a specific ticket, check whether an Issue Security Scheme is active on the project and whether the target issue has a Security Level that excludes the user.
4. Board Filter Query: If the user can open the issue via URL but cannot find it on an agile board, inspect the board's filter query (JQL). The issue may be excluded by the filter's WHERE clause (e.g., fixVersion is EMPTY or statusCategory != Done).

Pattern 2: User Cannot Be Assigned an Issue

When a user's name is missing from the Assignee dropdown list:

1. Check Assignable User: Verify that the user has the Assignable User permission in the project's permission scheme.
2. Check Browse Projects: Confirm the user has Browse Projects. A user who has Assignable User but lacks Browse Projects cannot be assigned issues.
3. Account Status: Confirm that the user's account is active and has product access. Inactive or unassigned identity accounts cannot be assigned work.
4. User Picker Filtering: If a custom user field is being used instead of the system Assignee field, check the custom field configuration context to see if user filtering is enabled (e.g., restricted to a specific group).

Pattern 3: User Has Edit Issues but Cannot Edit Fields

One of the most common ACP-120 scenarios involves a user who demonstrably holds the Edit Issues permission, yet cannot edit fields on a specific ticket. The four common causes are:

Deep-Dive: Workflow Properties That Lock Issues

Workflow status properties provide a way to override permission schemes based on issue state. The most critical property is jira.issue.editable:

• When set to true (or omitted), issue fields can be edited by anyone with the Edit Issues permission.
• When set to false, issues in that status can't be edited, regardless of what the project permission scheme allows. The issue can still be transitioned out of the status.

Other related workflow properties include jira.permission.* properties (e.g., jira.permission.comment.group or jira.permission.edit.denied), which programmatically suppress specific permissions while an issue resides in that particular workflow state.

---

The Permission Helper Diagnostic Tool

Jira Cloud provides a built-in diagnostic engine called the Permission Helper. It allows administrators to test and verify whether a user has a specific permission on a project or issue, and displays an auditable trace explaining why access was granted or denied.

Accessing the Permission Helper

The Permission Helper is part of the Jira Admin Helper, available to Jira admins:

1. Go to Settings > System > Admin Helper > Permission Helper.
2. Enter the user whose access you're checking. Leave the field blank to test anonymous access.
3. Enter the issue key, for example the issue the user can't see.
4. Choose the permission to check (for example, Browse Projects, Edit Issues, or Transition Issues) and select Submit.

Atlassian also documents a way for admins to check a specific user's access starting from a work item, which is handy when you're already looking at the problem issue.

+---------------------------------------------------------------------+
|                          Permission Helper                          |
|                                                                     |
|  User:       [ Alex Rivera                  ]                       |
|  Issue:      [ MOB-104 (Mobile Login Bug)   ]                       |
|  Permission: [ Edit Issues                  ]                       |
|                                                                     |
|  [ Submit ]                                                         |
+---------------------------------------------------------------------+
                                 |
                                 v
+---------------------------------------------------------------------+
|  Result: FAILED (User does NOT have permission)                     |
|                                                                     |
|  Analysis Trace:                                                    |
|  - 'Edit Issues' is granted to:                                     |
|      * Project Role: Developers (User is NOT a member)              |
|      * Project Role: Administrators (User is NOT a member)          |
|      * Dynamic Actor: Reporter (User is NOT the reporter)           |
|  - Conclusion: User does not belong to any entity with this grant.  |
+---------------------------------------------------------------------+

Analyzing the Diagnostic Trace

The Permission Helper evaluates:

• The project's active Permission Scheme.
• The user's Group Memberships.
• The user's Project Role Memberships in that specific project.
• Issue-specific dynamic roles (Reporter, Assignee).
• Active Issue Security Schemes and the issue's assigned Security Level.

What the Permission Helper Does NOT Check

A critical exam distinction: The Permission Helper evaluates the Permission Scheme and Issue Security Scheme, but it does NOT evaluate workflow conditions or screen configurations!

• If a user cannot transition an issue because a workflow condition failed, Permission Helper will not detect it.
• If a field is missing from a screen or hidden in a field configuration, Permission Helper will still report that the user has the Edit Issues permission.
• If an issue is locked by jira.issue.editable = false, Permission Helper may show that the user has Edit Issues in the permission scheme, even though the workflow property prevents editing.