Skip to main content
Version: Next

Field Configuration

The configuration of each encrypted field allows you to precisely define who can view its content, either statically or dynamically.

You have multiple ways to access the configuration of a field:

  • From the plugin administration panel: Navigate to the Secure Fortress Dashboard, locate the field in the Fields section, and click Configure.
  • From the dedicated field page (new in 2.3.0): In Jira Admin → Custom Fields, open the ··· menu of the encrypted field and select Secure Fortress. This manages the global configuration of the field.
  • From the native context configuration screen (new in 2.4.0): In Jira Admin → Custom Fields, open the ··· menu of the encrypted field and select Configure. Each field context displays its own Secure Fortress – Permissions & Scope panel independently.

Regardless of which path you choose, changes are reflected across all access points, since they all share the same configuration storage.

Dedicated Global Configuration Page

Starting with version 2.3.0, every encrypted field includes a Secure Fortress entry in the ··· menu on the Jira custom fields administration page. This access manages the global configuration of the field — the configuration that applies to all contexts that do not have their own override.

To access the global field configuration:

  1. Navigate to Jira Admin → Issues → Custom fields.
  2. Locate the encrypted field you want to configure.
  3. Click the ··· menu for the field and select Secure Fortress.

··· menu in Custom Fields showing the Secure Fortress option

The field configuration page opens with two sections:

  • Access permissions: view and edit the users, groups, issue roles (Reporter, Assignee, Creator, Watchers), and project roles authorized to decrypt the field.
  • Protection scope: configure whether the protection applies globally, by project, or by issue type.

Native field configuration page showing the permissions and scope sections

Direct URL access

You can also reach the configuration page directly by navigating to /plugins/servlet/secure-fortress-field?customFieldId=customfield_XXXXX, replacing XXXXX with the numeric ID of the field.

Global configuration

The configuration on this page acts as a fallback for all field contexts that do not have their own override. To configure each context independently, see the Per-context configuration section below.

Per-context configuration (new in 2.4.0)

Starting with version 2.4.0, you can define access permissions and protection scope independently for each Jira context of the field. This is especially useful when the same field is used across different projects or field schemes with different security requirements (for example, an "HR" context with access restricted to people managers and an "Operations" context open to all authenticated users).

What is a context?

In Jira, a context (or field configuration) determines which projects and issue types a custom field is available in. A field can have multiple contexts, each applied to different projects or field schemes.

How to access per-context configuration

  1. Navigate to Jira Admin → Issues → Custom fields.
  2. Locate the encrypted field you want to configure.
  3. Click the ··· menu for the field and select Configure (Jira's native option).
  4. The field configuration screen lists all contexts for the field. Each one includes the Secure Fortress – Permissions & Scope section.

Native field configuration screen showing the field contexts with a Secure Fortress panel in each one

Inheritance model

The configuration follows a two-level inheritance model:

LevelDescriptionUI indicator
GlobalFallback for all contexts without an override. Managed from the dedicated page (··· → Secure Fortress).Always active.
Per contextSpecific override for that context. Takes priority over the global configuration."Configured for this context"

When a context has no override, the UI displays "Inheriting the global configuration" in both the permissions and scope sections.

Context panel showing the global configuration inheritance indicator

Permission mode

When editing the permissions for a context, you will find the "Who can decrypt this field?" selector with two options:

  • All authenticated users: any logged-in Jira user can decrypt the field. No need to specify users, groups, or roles.
  • Specific users, groups, roles: access restricted to an explicit list of users, Jira groups, issue roles (Reporter, Assignee, Creator, Watchers), and project roles.

Reset to global configuration

If a context has its own override and you want to return to automatic inheritance, click the "Reset to global" button in the corresponding section (permissions or scope, independently). You will be asked to confirm before the override is removed.

Once reset, the context returns to displaying the "Inheriting the global configuration" indicator.

Limitation — Protection scope per context (partial support)

In version 2.4.0, the protection scope per context has inheritance support: contexts without an override inherit the scope configured in the global configuration. However, independent scope filtering per context (restricting encryption to specific projects or issue types within a given context) will be available in release 2.5.0.

Permission Types

Static Permissions (Groups and Users)

In the configuration window, you can directly assign viewing permissions to:

  • Jira Groups: Select one or more groups. All their members will be able to see the field's value.
  • Individual Users: Select one or more specific users to grant them access.

Dynamic Permissions (By Role in the Issue)

This functionality allows you to automatically grant viewing permissions based on the user's role within a specific issue. It is ideal for workflows where access to information depends on who is responsible for the issue.

  • Grant permission to Assignee: If this option is selected, the user who is currently assigned to the issue will have permission to view the field's value.
  • Grant permission to Reporter: If this option is selected, the user who created the issue (the reporter) will always be able to see the field's value.
Note

Dynamic permissions are evaluated in real-time. If an issue is reassigned, the new assignee will gain access, and the previous one will lose it (unless they have permission through another means).

New dynamic permission options

Protection Scope

When configuring an encrypted field, you can define the scope of the protection, meaning which part of your Jira instance the encryption will apply to. This allows you to protect only the issues that contain sensitive information and avoid unnecessary encryption in projects where it adds no value.

In the configuration window you will find three scope options:

  • Global: The field is protected across the entire Jira instance. This is the default behavior and applies to any issue that uses this field.
  • By project: Protection applies only to issues in the projects you select. In unselected projects, the field will not be processed by the add-on.
  • By issue type: Protection applies only to issues of the selected issue types (e.g., Incident or Change Request).

When you choose By project or By issue type, a multi-select picker allows you to choose one or more items from the corresponding list.

The configured scope is clearly displayed in the administration panel, so you can quickly identify the coverage of each encrypted field.

Note

Encryption and decryption are only applied to issues within the configured scope. Issues outside the scope are not processed by the add-on.

To save any changes to the configuration, click the Save Permissions button.

Any user who does not meet any of the permission rules (neither static nor dynamic) will not be able to see the field's content and will instead see the message [NO ACCESS], as explained in the user guide.

Revoking field protection

If you need to return this field to its original standard text state, you can revoke its protection from the Migration section of the Secure Fortress Dashboard. Please note that this action is irreversible and removes all configured permissions. See Protecting Existing Fields for details.