ACL error after upgrade

[JohnnySnow]

Hi Team,

We have a custom application with a table say ABC. This table is extended from task table. We recently upgraded from Vancouver to Washington (and the issue seems to happen post this). When the user is trying to open "Assigned to" the user receives this below error

Upon analyzing I can see that below ACLs are causing this issue

and user doesn't have any of the above roles.

I'm trying to understand if something has changed in terms of role in Washington release, why the issue didnt come up in Vancouver instance.

I'm assuming to resolve we can add the custom table role in one of the above ACL.

Is there any other way to fix and analyze why the issue came up after upgrade?

[Philemon Anton1]

I have seen the same or a similar error message on an instance which is on "glide-vancouver-07-06-2023__patch10-06-26-2024_07-11-2024_1109.zip". Suddenly, some users were not able to see records they saw before. It seems like this patch introduced two new operations "query_match" and "query_range". You can check if you have those in the upgrade history too:

/sys_upgrade_history_log_list.do?sysparm_query=file_nameSTARTSWITHsys_security_operation%5Edisposition%3D1&sysparm_view=

Those are not documented anywhere... We were able to prevent the error by creating new ACLs of operation "read" and also for operation "query_match" for the table/field in question. The error is now gone and users are able to see the records again. We created a case and are currently trying to get an answer what those new operations are and why they change the behavior of existing functionality.

[HarishVardineni]

I have faced similar issues after washington upgrade , we have checked (sys_search_source_list.do) records and noticed that there are  system created records with same table name and conditions with itil and admin read roles for one of the record. We tried to inactive one of the record that has itil and admin read roles but still error messages displaying. Once we have removed conditions like active = true or directly deleted the error record then issue resolved. 

[JohnnySnow]

We ended up creating read acls on the sys_user_grmember table.