Visibility Restrictions

Encryption for Jira includes visibility restrictions, which allow administrators to decide who can see which items on a page.

Attachments Permissions

With the Attachment Permissions, admins can decide who can open/download attachments. To set these permissions, complete the following steps.

  1. Click the Jira Administration icon, and select Issues from the dropdown menu.
  2. Select Permission Schemes from the left sidebar.
    The Permissions Schemes screen, accessed from the Jira left sidebar.
  3. Click the Permissions link for the permission scheme you want to configure.
  4. Scroll down to the Attachments Permissions section.
    The Attachments Permissions section of the Permissions screen.
  5. Click Edit next to Access Attachments, then add the users (or groups or project roles) who can open the attachments.
  6. Click Grant.
    The Edit screen for an attachment, accessed from the Permissions screen.

  • Reporters have access to their attachments whether or not they are specified in the permission.

  • All users are able to open their own attachments while they have access to the issue.

  • After installation, or after an update to this version, it is important to note this new permission type isn’t granted to any user. By default, users will only be able to open their own attachments.

Encrypted Custom Fields Permissions

Custom Field Permissions provide admins more control over the encrypted custom fields.

With this feature, you can decide who can view/edit encrypted custom fields. To set these permissions, complete the following steps.

  1. Click the Jira Administration icon, and select Issues from the dropdown menu.

  2. Select Permission Schemes from the left sidebar.

    The Permissions Schemes screen, accessed from the Jira left sidebar.

  3. Click the name of the?permission scheme you want to configure.

  4. Scroll down to the Issue Permissions section.

    The Issue Permissions section of the Permissions screen.

  5. Click Edit next to Access Encrypted Custom Fields, then select the required permission (group or users).

  6. Click Grant.

    The Edit screen, accessed from the Permissions screen.

Users without this permission:

  • Will see the encrypted value instead of the real value of the custom field.

  • Won’t be able to add or edit the values of encrypted custom fields.

  • Won’t see the Encrypted Fields History activity tab.

An example Jira issue, with the associated Encrypted field highlighted.

Bulk Change Permission Schemes

For Jira instances with multiple permission schemes, granting permissions can be a time-consuming process. Using a groovy script allows you to update the permission type for all the permission schemes for a specified group, user, or project at once.

Administrators can modify the following script to grant the "ACCESS_ATTACHMENT" or the "ACCESS_ENCRYPTED_CUSTOMFIELDS" permission type to the named user, group, or project role across all permission schemes. To do so, follow the steps below:

  1. Go to the Jira Administration menu, and select Add-ons.

  2. Select Script Console under the ScriptRunner section of the left sidebar.

  3. Paste the script included below this list of steps, but update the following values:

    • String permissionType: must be "group", "user" or "projectrole". For instance: String permissionType = "group".

    • String target: the target user, group or project role.

      • If permissionType = "group" then target must be the name of the desired group.

      • If permissionType = "user" then target must be the desired username.

      • If permissionType = "projectrole" then target must be the ID of the desired project role.

    • String accessPermission: the permission type. It must be "ACCESS_ATTACHMENT" or "ACCESS_ENCRYPTED_CUSTOMFIELDS".

      If you enter an invalid group or username, the entry is still created, and the permission schemes will continue working as configured. However, if you enter an invalid project ID, the entry is created, but the permission schemes could become corrupted. If this happens, you will need to manually remove the wrong rows from the database.

  4. Click Run. The execution result is displayed on the Logs tab.

  5. Modify and run this script for each group, user, or project role to which you would want to grant permission. If you run the script more than once for a target, do not worry; the record is created only once.

We recommend that you first run this script in a test instance.

Script to paste for Step 3 above:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.permission.PermissionSchemeEntry
import com.atlassian.jira.permission.PermissionSchemeManager
import com.atlassian.jira.scheme.SchemeEntity
import com.atlassian.jira.security.plugin.ProjectPermissionKey
import org.ofbiz.core.entity.GenericValue
import com.google.common.base.Objects
import org.apache.log4j.Logger
import org.apache.log4j.Level
def log = Logger.getLogger("com.adaptavist.jira.plugin.encryption.permissionscript")
log.setLevel(Level.DEBUG)
String permissionType = "group" //eg "group" or "user" or "projectrole"
String target = "jira-users" // the group, username or project role ID
String accessPermission = "ACCESS_ATTACHMENT" // "ACCESS_ATTACHMENT" or "ACCESS_ENCRYPTED_CUSTOMFIELDS"
PermissionSchemeManager permissionSchemeManager = ComponentAccessor.getPermissionSchemeManager()
ProjectPermissionKey permissionKey = new ProjectPermissionKey(accessPermission)
SchemeEntity schemeEntity = new SchemeEntity(permissionType, target, permissionKey)
def grantsNumber = 0
for(GenericValue scheme : permissionSchemeManager.getSchemes()) {
log.debug "Permission scheme '" + scheme.get("name") + "' (" + scheme.get("id") + ") - start"
boolean permissionExists = false
for (PermissionSchemeEntry permissionSchemeEntry : permissionSchemeManager.getPermissionSchemeEntries(permissionSchemeManager.getSchemeObject((String)scheme.get("name")), permissionKey)) {
if (permissionSchemeEntry.getType().equals(permissionType) && Objects.equal(target, permissionSchemeEntry.getParameter())) {
permissionExists = true
}
}
if(permissionExists) {
log.debug "Permission scheme '" + scheme.get("name") + "' (" + scheme.get("id") + ") - '" + accessPermission + "' permission already exists for '" + target + "' " + permissionType
} else {
permissionSchemeManager.createSchemeEntity(scheme, schemeEntity)
grantsNumber++
log.debug "Permission scheme '" + scheme.get("name") + "' (" + scheme.get("id") + ") - granted '" + accessPermission + "' permission to '" + target + "' " + permissionType
}
log.debug "Permission scheme '" + scheme.get("name") + "' (" + scheme.get("id") + ") - end"
}
log.debug grantsNumber + " schemes updated"`

On this page