Important update information

This page describes features introduced in Secure Fields 3.0. If you use older version of the add-on please click here.

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, in the Add-ons tab.

You can choose from 3 levels:

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 given amount, but still will not be able to see the preceise value of the Secure Field. This level enables fast and efficient search.
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.
Disabled - there is no option to search through Secure Fields.

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

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

Expand to read more about our recommendations on the Security Search...

Let's imagine you have two secure fields. One of them is called "budget" and stores strictly confidential financial information you don't want to expose. Second field is called "detailed bug consequence" and contains description of a bug you raised.

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 in result of the JQL search.

In the second case ("detailed bug consequence") you can use Performance mode as it's not possible to guess the long description.

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

Searching in "Strict" Search Mode

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).

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

1 - custom field's name

2 - operator's name

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

4 - case sensitive/insensitive
Note: the argument valid for operators = and != for fields: Secure Text, Secure Free Text, Secure List, Secure Multi Select List, Secure Single User Picker, Secure Multi User Picker, Secure Single Group Picker, Secure Multi Group Picker.

Note 2: Possible values are case_sensitive/case_insensitive

When using Strict Search Security Settings, you can use operators that are defined for the particular field types 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 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
isEmpty	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
startsWith	x	x		x	x	x	x	x	x			x	x
endsWith	x	x		x	x	x	x	x	x			x	x
contains	x	x		x	x	x	x	x	x			x	x

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

Secure Field Search with JQL

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

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

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

2 - custom field's name

3 - operator's name

4 - custom field's value

5 - case sensitive/insensitive

Note: Possible values are case_sensitive/case_insensitive

Secure Field Search with Filter

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

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

1 - Filter id - 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.