# Required permissions

#### By understanding the scope of resources that need protection, you can determine whether full Jira admin access or space-level administration is the appropriate level of permission.

***

## General permissions

### <mark style="background-color:blue;">Company-managed spaces</mark>

A **Jira** admin is required to back up not only individual spaces but also the broader set of global resources and company-managed spaces that may be accessed or shared by team-managed spaces, including any global resources used by those spaces.

With **Jira** admin access, **Xopero ONE** ensures that all global configurations—such as shared dashboards, filters, and automation rules—are properly protected.

### <mark style="background-color:blue;">Team-managed spaces</mark>

If you only need to protect specific **team-managed spaces that do not use global resources**, granting your **Jira** account administrative permissions at the space level is usually sufficient. With access limited to the team-managed space, **Xopero ONE** will not have access to global configurations.

{% hint style="success" %}
While space-specific administrative permissions can be used for team-managed spaces, we recommend granting **Jira** admin access to prevent access conflicts and ensure the space is backed up correctly.
{% endhint %}

***

## Permissions required to back up attachments

The following lists the permissions your **Jira** account must have for **Xopero ONE** to access, download, and back up all attachments in the protected space (project), based on the space management type.

### <mark style="background-color:blue;">Company-managed spaces</mark>

1. **Permission schemes** — to access attachments, your **Jira** account must have the **Browse Projects** permission for a specific space, either directly or through a group or role. You can change this permission by editing the scheme assigned to the space or by assigning a different scheme.

{% hint style="info" %}
To edit a specific scheme, open it either from the **Permissions** section within the space settings or from the **Work Items** section in the **Jira** instance settings.
{% endhint %}

{% hint style="danger" %}
**This permission must be configured in every Permission Scheme assigned to the spaces whose attachments need to be backed up.** While a single scheme can be shared across multiple spaces, each space typically creates its own default scheme, which must be updated accordingly.
{% endhint %}

{% hint style="warning" %}
If the permission is granted indirectly—via a group or role—your **Jira** account must belong to that group or role.
{% endhint %}

2. **Issue access restrictions** — if a space uses a work item **Issue Security** scheme and contains issues with restricted access that include attachments, your account must belong to **at least one Security Level assigned to each issue**.

{% hint style="info" %}
This setting is not enabled by default and will not restrict access to attachments until it is configured.
{% endhint %}

3. **Comment restrictions** — if an attachment is part of a comment with restricted access, your account must belong to the role or group that has access to this comment.

### <mark style="background-color:blue;">Team-managed spaces</mark>

1. **Space visibility** — for spaces with **private** or **limited** visibility, you must be a member of the space to access and then back up its attachments. The assigned role and its permission scope are not relevant; space membership alone is sufficient. For all other visibility levels, attachments are accessible to the public and do not require any additional roles or permissions.
2. **Issue access restrictions** — if an issue or a comment has an access restriction applied, its attachments are visible only to users who have at least one of the roles specified in the restriction. The role name and permission scope do not matter — your **Jira** account only needs to be assigned one of the specified roles.