getting an error while looking up any incident ticket

[shaa066]

part of the query on live_message has been ignored because of insufficient access for 'query_match' operation on live_message.chat_message error on servicenow

[Philemon Anton1]

Hey Alex

In my case the error showed up on a "assigned_to" field from a table extending the task table. There is a reference qualifier on it (roles=sn_cd.content_admin^ORroles=sn_cd.content_manager^active=true) and it shows the following error when trying to select a user:

I have no idea why it would complain about sys_user_grmember, as the reference is to the sys_user table and I don't see any query about sys_user_grmember in my reference qualifier. I was however able to prevent the error by just adding a "query_match" ACL for exactly the table/fields in question. In my case I did even a * ACL to cover all fields:

That seems to do the job and the error does not show anymore and I can assign the tasks again. It is still very weird to not find anything about this "query_match" operation type and also why it is complaining about sys_user_grmember.

Hope that helps.

[Christoph Lang]

We observed the same (strange) behavior and created an support case as well. 

The new ACL seems to be blocking reference qualifier from working correctly if fields are used in the reference qualifier where the user does not have read access.
Unfortunately this is expected in our environment.

We want to filter out records based on conditions.
But the enduser does not need to have read access to these fields.

Furthermore it seems to be applied to the reference popup only.
And not when the record is selected via "**".

-> This is also not consistent.

[Christoph Lang]

My HI Case regarding the !query_match" ACL is currently ongoing. I just want to share some information i could collect until now.

1. I want to read more about the ACL type "query_match". Pleas provide documentation (links) about it.
-The Query ACL that got introduced in Xanadu and was backported to VP10 and WP5 merely replaces READ ACLs with Query ACLs (query_match /query_range) when it comes to query evaluation.
Out of the box, these query_match / query_range ACLs (we ship *.* query_range and query_match ACLs) relies on READ ACLs through a security attribute.
The warning message that says "read security rules" too gets replaces as "query_match/query_range" security rules.
query_range, Enables users to submit range queries("starts with", "ends with", "contains", etc) and sorting is unrestricted.
query_match, Enables users to submit match queries("is", "is not", "is empty", etc).

2. What is the purpose of this ACL?
- It replaces Read ACLs within Query ACLs

3. Why is only the popup affected by the new ACL and not the reference field in general
- ACLs are now enforced on the columns used in a query condition. This must have been enforced with reference qualifier queries as well. If the user doesn't have read access on a column used in the query condition, the query will fail and no rows will be returned. This is expected. Query *.* ACLs introduced as part of VP10/WP5 are just redirecting to Read access check via hasRightsToReadIsTrue security attribute.

Some questions are unanswered for now:

1. If this is a new feature and was recently introduced by a Patch, could you please provide the link to the documentation as well as the Release notes in where further information are given?

3. Why is the Reference field still working if "**" is used directly within the field but is not working if the Reference lookup is used (see attached screen recording)? Both logic should work similar in regards to Reference Qualifier.

[Christoph Lang]

ServiceNow Support finally shared the link to the documentation:

Solution Proposed:
The below document provides details regarding the 'query_match' and 'query_range' ACLs.
https://docs.servicenow.com/bundle/xanadu-platform-security/page/administer/contextual-security/conc...

However, i still have questions which are unanswered until now:

However i still have questions.

I understand the query_match ACL is there to allow for more specific control of user queries.
This is good and i can agree to that.

The problem that I have and don't understand is especially with the Reference Qualifiers of dictionary fields.

See a Reference qualifier is a hard-coded filter that was set up by the admin.
The admin defines the reference qualifier on a field to limit the records that an user can select.
The admin might want to filter the data based on fields, which should not be available to users.

Once the popup is opened from the magnifying glass the user can put in "own" filter criteria / encoded query.

Therefore the resulting Database Query consists of two parts

Reference Field = Reference Qualifier (admin configured - not changeable) + User Query (optional)

So the "Reference Qualifier" part filter is not a user input as it cannot be changed by the user.
This is admin configured filtering

Furthermore:
It seems to be applied to the reference popup only.
And not when the record is selected via "**".

This is not consistent.
So why is the query blocked when opening the popup but now when doing the search via "**" ?

For me it is
* Not consistent.
* Not described why it is not consistent.
* There is no word about reference fields and reference qualifiers in the documentation, especially that this also impacts this (at least in the popup, not in the wildcard search)

[usha14]

Hi Philemon, 

Could you please let me know what is the workaround ACL that are created