Access policies

1 min read

Access policies decide who can do what with advanced filters on this installation. There are four grants, and the defaults are deliberately sensible: most sites never need to change them.

Open Global settings → Access policies to see them.

The four grants #

Grant Covers Default
Create advanced filters Making new advanced filters Everyone logged in
Manage all advanced filters Editing, archiving and deleting every filter, not just your own Jira administrators
Run bulk operations Archiving, reactivating, deleting and reassigning in bulk Jira administrators
Export usage and backups Downloading the usage report and the configuration backup Jira administrators
i
Leaving “Create advanced filters” open to everyone is the recommended setup. People can only build on Jira filters they’re already allowed to use, so it grants no access to data they didn’t have. Narrowing it mostly just creates ticket queues for your admins.
The four policy rows collapsed, each with its name, what it applies to, and its current audience.
The four grants, each showing who currently holds it.

Delegating a grant to a group #

Select Edit on a row. You’ll be asked who holds this permission before you’re asked for groups:

  • Create advanced filters: All logged-in users, or Specific groups.
  • The other three: Jira administrators, or Jira administrators and specific groups.

Choose groups by name; they’re stored by id, so renaming a group in Jira later won’t break the grant. Up to 100 groups per grant.

A grant open for editing, its mode set to Jira administrators and specific groups, with one group chip added.
Choose the mode first, then the groups.
i
Jira administrators always hold all four grants, whatever the groups say. Narrowing a grant to groups they’re not in won’t lock them out. That’s why a delegated row reads “Jira administrators + Group A, Group B”.

A safeguard worth knowing about #

Clearing the last group chip doesn’t revert to the default. The row stays in group mode with Save disabled, and asks you to add a group or choose the other mode. This is deliberate: an empty list is the legitimate way to store “the default”, so treating a deleted chip as one would silently widen the grant instead of narrowing it.
A policy row whose last group chip has been cleared, with Save disabled and the message under the picker.
An empty list in group mode is refused rather than quietly widening the grant.

If another administrator saves the same grant while your row is open, the row tells you and refuses to overwrite their change.

What happens when you save #

Changes take effect immediately, for everyone. Nothing about any existing filter’s configuration changes: no administrator lists are touched. What changes is the answer the next permission check gives.

So widening Manage all advanced filters lets its new holders manage every filter that already exists from the moment you save, not just ones created afterward. Worth bearing in mind before you add a large group.

Who can edit policies #

Jira site and organization administrators only. This grant can’t itself be delegated.