Number of rows removed from this list by Security constraints on cmn_notif_message table for non-admins: How to fix without using before query solution?

[BabyYoda]

I'm trying to ensure that any user who has records in the cmn_notif_message table--by way of the User field value equals the current session User's Sys Id--has read access to their respective records. Ergo, if Sally has 10 cmn_notif_message records, Sally should be able to see (but not necessarily edit) 10 of her records.

I turned on debug security and one ACL I found which is a factor but not necessarily the root cause is the read ACL on Type record with Name as cmn_notif_message. The description of the ACL is: "user can read cmn_notif_message records for their own user records".

Its constraints are user must have the snc_internal role and the Condition is "user=javascript:gs.getUserID()^EQ". For an admin, it passes with flying colors. For Sally, a non-admin user, I see this when I open the ACL from the debugger: 

"User not allowed to access table: cmn_notif_message."

I created a Business Rule to print to the logs the value of current.user on a before query and tested against the admin user and the non-admin user use cases. The value of current.user was the Sys Id of the admin in the former and empty in the latter case. For the admin, since both sides are equal, it matches and the ACL would evaluate to true. For Sally, the non-admin, her current session User Sys Id is good but the User field on the cmn_notif_message table comes up empty and, thus, the ACL check evaluates to false.

I understand that I can leverage the Before Query method to modify the query and that will resolve the issue. In fact, I implemented it and it does indeed work and Sally can see her 10 records. But I'm afraid I don't quite understand what's going on with these ACLs.

What ACLs do I have to modify to create to allow Sally, the non-admin user, to see her records in the cmn_notif_message table?

The ACL I discussed above should be the one which allows non-admins to see their own records, or so I thought. But then tracing the security rules reveals that the non-admin user doesn't even access to the table to evaluate the Condition above! Ergo, "user" should equal the value of gs.getUserID() but it can't evaluate because the non-admin user doesn't have access to the table, let alone the user field perhaps. And, yet, creating a Before Query Business Rule resolves this issue.

(Does the Before Query Business Rule run before the ACL checks or after the ACL checks?)

What should I do here? How can I resolve this without using Business Rules and sticking to either modifying or creating ACLs?

[Uncle Rob · Accepted solution]

According to this Knowledge Article (updated May 2022) you still can't get rid of that "security constraints message" and they advise using a before query rule.

[BabyYoda]

Thank you, Robert. Yes, I should clarify my original post that I inaccurately thought none of Sally's records (non-admin user) were loading, when in fact they were loading but you have to exhaust the full list, paging through all results, or filter the query, which goes back to the before query Business Rule (BR). So, yes, to your point, BR Before Query is the proper workaround solution until ServiceNow says otherwise and points to a different, better solution.