ACL is not restricting access

[kirkr]

I have a custom table within an application that extends the Task table. There is an ACL that restricts write access to a specific role, all users have have write access when tested via impersonation. I've attempted to debug this and got even more confused.

Additionally, the ACLs work as expected in our development copy of the application. This issue only occurs in our production environment after a first time fresh install of this application. I've also verified that no other tables that extend the Task table are visible to users that shouldn't have access just in case.

Here is the debug output that appears to indicate write access at the record level

All three criteria appear to pass

• Roles (Roles=No Roles)(Result=True)
• Condition (Result=True)
• Script (Result=True)

This ACL should fail at Roles (Roles=No Roles)(Result=True), because there is a role associated to it and that appears to be the issue. The user also does NOT gave the role the ACL is set to require.

I've cleared the cache with cache.do but had no effect. Does anyone have any idea what may be going on?

Here is a screenshot of the ACL after clicking on the link to the rule in the debug message.

[Pradeep Sharma]

Hello,

I can take a look and debug the issue If you can install the app on your personal dev instance. Please let me know.

[kirkr]

I truly appreciate your willingness to help, but unfortunately this is on our internal company instances and not on a personal dev instance.

[kirkr · Accepted solution]

I believe this is a false alarm after further testing, of course after I made this whole post.

It seems that ServiceNow was mixing certain access between my account and me impersonating other users. I have never seen this before, but going to a different browser and testing properly blocked users from reading and writing per the ACLs.

In case anyone else experiences this, here were the symptoms I had

• Everything works as expected in our development instance via impersonation
• Installing this on our production instance and testing via impersonation I noticed that users without the proper role and users without a role could read, write, and delete records from the new table in the application
• ACL debugging showed the impersonated user passed the ACLs
• Menu items that are restricted by role were correctly not appearing for impersonated users
• UI Actions that are restricted by role were correctly not appearing for impersonated users
• Clearing the instance cache via cache.do had no effect
• Using a different browser and starting a new session displayed the correct behavior

Never seen this before, but I'm happy it was a false alarm.