Restore Deleted Entities screen seems to bypass entity permissions for the current role

this is a security issue when Soft Deleted entities are in effect for the entire application:

  1. setup a couple of roles, one that denies everything (Denying), and one that has only Read permission for an entity (for example I tried with the sec$Permission one) and has the permission to show the Restore Deleted Entities screen
  2. assign the aforementioned roles to a user
  3. edit the role adding a permission, saving it and then deleting that permission (just to have a permission record with deleteTs set)
  4. login with the user created in point 2)
  5. open the Restore Deleted Entities screen and select the sec$Permission entity. You’ll see the permission deleted at point 3)
  6. select the deleted permission, and click Restore. The record will be updated (undeleted) even if the user DOES NOT have update permission on the sec$Permission entity

It seems that the permission check does not prevent updating the system attributes deleteTs, deletedBy, updateTs and updatedBy

I wanted to give a power user the ability to restore deleted entities, but given the above problem I cannot trust that screen, it’s a potential security breach.

Maybe I’ll extend or replace the screen by filtering out entities that are not part of the application namespace, but nonetheless it surprises me the fact that the user can effectively update the state of read-only entities



Entity restore screen is designed to be used by application administrators. It is also supposed that administrator has all permissions to all entities in the system. Moreover, entity restore is risky. So simple users (to whom security settings are applicable) should not have access to the screen.
Imagine that the deleted entity had multiple (mandatory) relations to other entities, and all of them were cascade deleted. Now we want to restore the entity, and if we have no rights to edit some of the related entities, the system might be broken.

It is OK that role permissions were ignored in the described case.

1 Like

that’s a reasonable explanation, but it’s something that you need to include in docs ASAP.

I’ve seen other users here and in the chat asking for the restore functionality, and I’m not 100% sure they DON’T intend to open it to regular users.
In my case I extended the screen and applied custom security checks, parametrized by new UI specific permissions, but other less experienced devs may expose the screen directly to users…


Hi, Paolo.
The documentation will be improved soon.