Privileged Queries feature

The Privileged Queries feature works in conjunction with the security context feature. For more information, review the Hiding records topic in the Creating a security model section.

A privileged query is a special query that allows the result set to include records that are not otherwise visible to a regular user (one who is not a Security Administrator). The display fields of the query determine what parts of a hidden record can be seen by a regular user.

Note: To use the Privileged Queries feature, you must have the Reveal Existence feature feature enabled.

The purpose of a privileged query is to show some record data without revealing any sensitive information. If a record is hidden from a user, that user will not be able to open the record to see all its content. They will only see what is included as a display field in the result set itself.

For example, a privileged query could be used to show the headline and description of a Defect record, but not expose the fields that provide details about the analysis and fix for the issue. That would allow a normal user to learn about a similar defect to avoid submitting a duplicate. To help make that decision, the privileged query could include a few more details, such as the owner, so that the user could check with that person to see if the defect has been fixed or whether the conditions really are similar enough to be considered a duplicate.

Note:

The feature requires at least Feature level (FL) 10 or higher.

The feature can be enabled or disabled for specific databases or entire database sets via setting two master properties "PRIVILEGED_QUERY_FEATURE" and "ALLOW_PRIVILEGED_QUERIES". See the installutil setmasterproperty topic to get how to set a master property.

For example, to enable the feature, run the following commands:
installutil setmasterproperty 2.0.0 admin "" ALLOW_PRIVILEGED_QUERIES "1"
installutil setmasterproperty 2.0.0 admin "" PRIVILEGED_QUERY_FEATURE "Enabled"

Only a security administrator can create a privileged query. When the feature is enabled, the query editor will show a Privileged Query check box above the query filters.

privileged_query

A Security Administrator can check this box to make any query be privileged or remove the check mark to make it be a normal non-privileged query. The Security Administrator can modify a privileged query in the same way as any other query, and the query will retain its privileged status.

A regular user can never check the Privileged Query box. But a regular user can remove the check mark to run the query as non-privileged. When doing so, the user will first see a confirmation dialog because the change cannot be undone.

confirm

In general, a regular user cannot modify a privileged query without the query losing its privileged status. If a regular user makes any change that would cause privilege loss, the change is either prevented or the user is warned that the change cannot be undone and must confirm the change before it is made.

This feature defines a set of fields for one or more record types that are allowed to be used in a privileged query, which will run as if security context was not enabled, via setting a master property "PRIVILEGED_QUERY_FIELDS". This value forms a "whitelist" of fields that can be added to a privileged query by a user that does not have the security administrator privilege, without making the query lose its privileged status.

Note:

In the "whitelist", each name is expected to identify a record type and the value is a comma-separated list of fields within that record type. Entries for each record type are separated by a semicolon. For example, to allow a non-privileged user to change a privileged query to display or filter on the ID and Owner fields of a secured Defect record type, and the ID, Owner, Status, and Priority fields of a secured Task record type, run the following command:

installutil setmasterproperty 2.0.0 admin "" PRIVILEGED_QUERY_FIELDS "Defect=Id,Owner;Task=Id,Owner,Status,Priority"

It is possible for a user to have the SQL Editor privilege and not have the Security Administrator privilege. Such a user cannot edit the SQL of a privileged query without first removing the privilege status.

It is important to understand that although such a user cannot create a privileged query directly, they could achieve a similar result since the SQL statement being used may cause hidden records to be included in the result.

The ability to edit and create a privileged query is available only in the web interface. The other UI clients do not identify a query as privileged, but they can run an existing privileged query. The result will be the same as when it is run in the web client. When a privileged query is edited in the other UI clients by a normal user, any change that would cause privilege loss will be prevented.

When privileged queries are being used, the Reveal Existence feature should be enabled. Although this is not required, it will avoid potentially confusing situations. When a normal user tries to open a hidden record from a result set produced by a privileged query, the user would be told that the record does not exist, which is not consistent with what is shown in the result set. When Reveal Existence feature is enabled, a normal user would instead be told they do not have privilege to view the record. See the Reveal Existence feature topic for more information.

privileged_queries

This feature can also be used with the List View Query feature, to run user-defined, privileged queries. For more information, see the technote 21990415.