Aside from the KB article referenced in this post, here is what HI responded with:
As a part of Vancouver patch 7 and Washington patch , there was a feature added to plug a security risk where a user can query for data that they don't have explicit read access to. The error message seen in this task is because of the same feature. It is likely that the user does not have access to certain fields (the same one in the error message: "Part of the query "). This is therefore an expected error message.
There are 4 options to resolve this:
Option 1:
Allow the user read access to the field that gives the error message. A more specific role can be created with limited access should the customer choose to.
Option 2 [Washington Patch 3 and above]:
Disable this feature for the specific table. Create this System Property and set its value to true: disable_field_acl_enforcement.global=
For example: disable_field_acl_enforcement.global=live_message
Option 3 [Washington Patch 3 and above]:
Disable this feature for the specific field. Create this System Property and set its value to true: disable_field_acl_enforcement.global=.
For example: disable_field_acl_enforcement.global=live_message.chat_message
Option 4:[Before Washington Patch 3]
Disable this feature entirely for this instance. Create the following system property to prevent the errors from popping up.
Name : glide.db.encoded_query.field_acl_error_msg
Type : true | false
Value: false
I understand why we are getting the messages and I don't disagree with the logic in providing a secure environment. However, I don't agree with three of the options provided to "address" the errors (disabling acl enforcement.) Seems counter-intuitive to do that.
I am going to try creating a read ACL for itil users for the two specific fields.
