Secure Fields for JIRA
Page tree
Skip to end of metadata
Go to start of metadata

Safety considerations and limited access to some of the data necessitated the introduction of additional features to the search engine.

In Secure Fields 3.0 we created 3 Search Security Levels, so you could choose which option is the best for your organization. You can set it up in the Search Security Level Configuration menu:

  1. Log in as a user with the 'Jira Administrators' global permission.

  2. Navigate to Admin menu →  Manage apps. Select Secure Fields → Search Security Settings.
    (info) Tip: Keyboard shortcut: g + g + start typing search security..

  3. Click the Global settings button to select a search security level.

Search security levels

  1. Performance - gives you an option to easily search through Secure Fields with full JQL capabilities. The possible downside is that anyone will be able to perform search and see for instance values bigger/smaller than the given amount, but still will not be able to see the precise value of the Secure Field. This level enables fast and efficient search.

  2. Strict - has the same rules as the previous Secure Fields version had - limited JQL search, but harder for unauthorized people to find any information.  Once you decide to upgrade to Secure Fields 3.0 all your secure fields will be automatically saved as Strict. We have also optimized search for this level, so if you decide to keep it this way, you will still feel the improvement in speed.

  3. Disabled - there is no option to search through Secure Fields.

+ you can define your own "Custom" search level.

Take under your consideration that changing configuration will likely demand you reindexing Jira.

Let's imagine you use many secure fields of different types. One of them is called "budget" and stores strictly confidential financial information you don't want to expose. The second field is called "detailed bug consequence" and contains a description of a bug you raised. Another field is Secure Single or Multi Select List.

In the first case ("budget") we recommend using Strict search mode. Using Performance mode, in this case, may cause that some unprivileged and advanced users can try to examine the field content by subsequent querying for different values, such as budget > 1000 then budget > 10000, etc. They will not be able to see the field content, but issues that meet the condition will be returned as a result of the JQL search. Strict mode is recommended for Secure List fields as well, so unprivileged users will not be able to see list’s values via search.

For "detailed bug consequence" you can use Performance mode as it's not possible to guess the long description.

You can use operators that are defined for the particular field types and are listed below:


Secure Text

Secure Text Field

Secure Number

Secure List

Secure Multi Select List

Secure Single User Picker

Secure Multi User Picker

Secure Single Group Picker

Secure Multi Group Picker

Secure Date

Secure Date Time

Secure Component

Secure Single Version Picker

Secure Multi Version Picker

Masked Secure Text Field

=

x

x

x

x

x

x

x

x

x

x

x

x

x

x


!=

x

x

x

x

x

x

x

x

x

x

x

x

x

x


>



x







x

x





>=



x







x

x





<



x







x

x





<=



x







x

x





isEmpty

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

isNotEmpty

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

startsWith

x

x


x

x

x

x

x

x



x

x

x


endsWith

x

x


x

x

x

x

x

x



x

x

x


contains

x

x


x

x

x

x

x

x



x

x

x


Searching in Strict Search Mode

Please note that in Strict search mode there is no JQL autocomplete for secure fields.

If you decide not to upgrade or stay with the Strict level of Security Search, you can still improve your efficiency search. 

The Secure Field plugin adds "issue in search" function to the JQL. This function takes from 2 to 4 arguments rounded by quotation marks.

Performance note

Please note that using the secureFieldSearch() function on large instances may cause performance issues. We strongly recommend using secureFieldSeachJQL() or secureFieldSearchFilter() functions instead. Please be aware that these functions have a parameter to enter the JQL Query/filter and we recommend using selective filters. It's not recommended to search for secure fields on a large dataset (more than 1000 issues).


Searching functions

Secure Field Search

issue in secureFieldSearch("", "", "")

(“custom field's name”, “operator's name”, “custom field's value”)

Note: the custom field's value is not required in the case of using operators such as isEmpty or isNotEmpty.

Important: Possible values are case_sensitive/case_insensitive.

Example of use: issue in secureFieldSearch("Secure List Field", "contains", "3.0"); issue in secureFieldSearch("Secure List Field", "isNotEmpty")

In large instances, due to better performance, please refer to functions described below as they allow you to search within secure fields in a limited range of issues.

Secure Field Search with JQL

This function allows searching within the result of other JQL. It takes from 3 to 5 arguments rounded by quotation marks. 

issue in secureFieldSearchJQL("", "", "", "")

(“any JQL - like project = test, issuetype = Task, etc...”, “custom field's name“, “operator's name“, “custom field's value“)

Example of use: issue in secureFieldSearchJQL("updated >= -1d", "License key", "isNotEmpty")

Please keep in mind that if your JQL contains any double quotation marks, please escape them - change to \" or change to single quotation marks '.
For example for a JQL like project = "Some Project" change it to project = \"Some Project\"

Note: Possible values are case_sensitive/case_insensitive.


Secure Field Search with Filter

This function allows searching within the result of a search filter. It takes from 3 to 5 arguments rounded by quotation marks. 

issue in secureFieldSearchFilter("", "", "", "")

(“filter id”, “custom field's name“, “operator's name“, “ custom field's value“)

To obtain a filter id (the filter id it is NOT a filter name, we are using filter ids because of the fact that the id filter name is not unique within an instance of JIRA) please execute a filter and check your web browser address bar. The number after filter= will be your filter id. 

Example of use: issue in secureFieldSearchFilter(10400, "Secure User field", "!=", "John Smith")

Note: Possible values are case_sensitive/case_insensitive.