Part of the query on sys_choice has been ignored because of insufficient access for 'query_match'

CharlieNZ
Tera Contributor

I hope this is the right place for this.

We have a user that has started getting these on each Incident they view:

Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.name
Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.inactive
Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.dependent_value
Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.element

charlesmeyer_0-1747600130406.png

 

We haven't made any changes to their account. The issue wasn't there a week ago. 

 

 

1 ACCEPTED SOLUTION

Hello @CharlieNZ 
My investigation shown that in fact, users didn't have read access to the field specified in the error message, visible in the below screenshot. All of that due to all sys_choice.* ACLs.

KonradMlodzik_0-1747728382087.png
My approach from here was to create sys_choice ACL for each of the fields that were prompted in error message, so in my case sys_choice.element and sys_choice.dependent_value.
I made them similar to the existing read ACL sys_choice.label.
Here you have an overview how I created that ACL:

KonradMlodzik_2-1747728919662.png


And as you can see here now in Access Analyzer, access is evaluated to true

KonradMlodzik_1-1747728858696.png

Try this approach with at least one of the fields from sys_choice that you have mentioned in yours error messages and see if the error still occurs. For me that works

If you can please mark that as helpful and that resolved your issue so that can help other visiting this thread 🙂

 

View solution in original post

15 REPLIES 15

I added a query_match and a query_range ACL for .* on the table I was having trouble with and deactivated all of the field level query_match ACLs for the same table. That resolved the issue for me. 

Konrad Mlodzik
Tera Expert

I have same issue and for now found out that the only query_match ACL which I have in my instance is *.* 

KonradM_odzik1_0-1747655670555.png

It should give access to the query_match operations to if user have READ rights on table/record but in my case users have READ access on sys_choice but still this error shows up and mess with few custom fields in incident form.

I'm investigating that with a team further and if we'll find anything I'll post update here

Thanks, I have hidden the messages for now using the System Property glide.db.encoded_query.field_acl_error_msg

Hello @CharlieNZ 
My investigation shown that in fact, users didn't have read access to the field specified in the error message, visible in the below screenshot. All of that due to all sys_choice.* ACLs.

KonradMlodzik_0-1747728382087.png
My approach from here was to create sys_choice ACL for each of the fields that were prompted in error message, so in my case sys_choice.element and sys_choice.dependent_value.
I made them similar to the existing read ACL sys_choice.label.
Here you have an overview how I created that ACL:

KonradMlodzik_2-1747728919662.png


And as you can see here now in Access Analyzer, access is evaluated to true

KonradMlodzik_1-1747728858696.png

Try this approach with at least one of the fields from sys_choice that you have mentioned in yours error messages and see if the error still occurs. For me that works

If you can please mark that as helpful and that resolved your issue so that can help other visiting this thread 🙂

 

Thanks,

 

This worked for me