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.
Right now the flow of loading and editing the access control configuration of an evee is as follows:
perspectiveId,remote.accessControl.getPermissions().<cortex-pattern entity=${permissions}>SET_CAN_WRITE.While there must be a way to know if a user
canWritea 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 thegetPermissions, 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
canWrite(pid)which receives a perspectiveId and return true if the logged user on that remote can update the evee.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.