Why does the Read Only role, snc_read_only, allow editing sys_user_preference table?

[mtatro]

In my custom SN developer instance https://dev20752.service-now.com/ as well as any new instance spun up, I am able to go to the "User Preferences" menu and edit fields directly if admin and snc_read_only is applied. This seems to be a counter to what the Wiki article at http://wiki.servicenow.com/index.php?title=ServiceNow_Read_Only_Role says "Once you assign this role to a user, they can no longer can create, update, or delete records on ANY tables."

Any thoughts? is this a bug? is this intended?

And finally is there a way to correct for this?

[Sharique Azim]

Are you logged in as an admin?

Matt Tatro wrote:

... edit fields directly if admin and snc_read_only is applied. 

Then anyways ACL would be over ridden by admin roles.

[mtatro]

I do not believe this is correct for the following reasons;
1) "Note: These role restrictions are in place even if impersonating another user with write access such as an admin." -https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/user-administration/...

2) This does properly block access from editing any scripts, any notifications, any system settings, any incidents, any changes, etc etc.

Thoughts?

[corina]

Hello Matt.

Impersonating could act differently than logging as the user itself.

What happens when you remove the admin role?He   still can edit?

The admin override acts indeed as sharique mentioned.

[mtatro]

Sorry for late response. Got caught up with other things and never go to reply. I did get to test this. I removed the admin role, applied ITIL, and kept the read only role. The user (my test account) had full access to edit their user preferences using the list view or the form view for a preference.

It makes sense to have them be able to edit their own, but if they are an admin role paired with read-only role that means they can edit anyone's preferences which does not seem like the best option.

I do not think this has to do with admin override because no other tested tables/forms allow for modifications while the admin role is active, and it explicitly says it should not in the documentation.