Rethink access control patterns

[pepoospina]

Right now the flow of loading and editing the access control configuration of an evee is as follows:

• the remote is derived from the perspectiveId,
• the permissions object is derived from remote.accessControl.getPermissions().
• the permissions object is recognized sing a registered pattern and a lense is selected and rendered using the <cortex-pattern entity=${permissions}>
• the lense includes mutations to the permissions and uses GQL mutations like SET_CAN_WRITE.
• the GQL mutation read the entityId and the mutation parameters, derive the remote again and call accessControl.setCanWrite.

While there must be a way to know if a user canWrite a given evee independently of the remote of the evee (to prevent the UI from allowing a user to perform actions that will be blocked by the remote), it seems that the getPermissions, its patterns and its functionalities (mutations), should not be a generic module.

It seems more natural that the access control is close to where it lives: near the EveesRemote. It seems that what is needed is that the remote.accessControl is forced to have

• one method canWrite(pid) which receives a perspectiveId and return true if the logged user on that remote can update the evee.
• one method getAccessControlLense() which return the web-component to render and edit the access control of that evee.

No need to register intermediate patterns, common mutations, or anything else.