tl;dr

When no one in your organization including system administrators can create or update personal views, check that you don’t have any plugins registered on all entities to run in a context different from a calling user.

Mundane details

Symptoms: when personal views are created or updated, all users including system administrators receive the following error:

SecLib::AccessCheckEx failed… snip … ObjectTypeCode: 4230… snip … AccessRights: ReadAccess

Object 4230 is userquery entity, a.k.a. personal or saved views. But how could it be that even system administrators are denied access?!

Personal views are special – you cannot grant privileges in any scope but the user. Go ahead, open Settings > Security > Security Roles > Any role and try to change the scope for Saved Views. See how only nothing or user is available? That means that even system administrators do not have access to other users’ views.

Enter a plugin on all entities. It kicks in when users are saving the views and needs at least read access to the entity. But since security context has been changed to another user, permission is denied.

Solution is either to change the plugin to run under a calling user context or not to register the plugin on all entities. Generally speaking, registering plugins on all entities is an extreme step and should be avoided.

One of the popular ISV solutions, Adxstudio portals (version 7 and below), actually has the cache invalidation plugin registered on all entities and the recommendation would be to re-register this plugin only for entities that you care about in the portal.

Thanks to the awesome investigative work of Matt “Europäischen Wurzeln” Wittemann and Shan “Smoke ’em” McArthur.