Extend web2 access control logic

[pepoospina]

Extend the UI permissions-admin component to have multiple members with different roles of canRead, canWrite and canAdmin each.

Context - Permissions UI Architecture

The permissions UI is dynamic, in the sense that the component that is used to see and configure the access control of a perspective depends of the type of permissions that entity has.

Dynamically show the access control UI for a given remote

The process starts at component (which is the one shown in the Wiki's home page), where the component is used sending it the perspective id (this.uref).

The PermissionsForEntity component loads the permissions of an object using the GraphQL query to fill this.permissions. Internally, the query uses a _context special property to read, from GQL, the patterns of an object. It then selects the accessControl property, which was registered as a pattern of a perspective here. Because the pattern was registered, _context query exposes acccessControl which is an object with a canWrite boolean property and a generic permissions object.

The permissions object is returned by the EveesRemote, and depends on each remote. For the EveesHttp, the access control is a BasicAdminAccessControlService type of object, which can be public or private, with different canRead, canWrite and canAdmin users as lists. Ultimately, the permissions for an entity is given by this HTTP request to the API.

Going back to the component, the permissions object is sent to a component called cortex-pattern, which is a component that receives an object, and renders it using the lenses registered to that component.

The pattern for an object that describes the permissions on the API is here, and it includes a lenses which uses the <permissions-admin> component to render the permissions.

This is where we currently show the "owner" as the canAdmin[0] user, and let that user make the perspective public or private.

Task - Extend UI to configure access control

Using the permissions-admin as a reference, create a new component in a file called permissions-admin-inherited.ts which will be able to show if the permissions of an entity are inherited from another one or not (use this wireframe as a guideline).

• [x] Change the AccessControl property of the EveesHttp remote to return not only the permissions of an entity, but its delegation configuration. It should return an object like this

{
    delegated: boolean;
    delegatesTo: string;
    permissions: BasicAdminPermissions 
}

• [x] Register a new pattern next to the permissions-admin one. Change the recognize function to work when the input object has those three properties, and change the lenses "behavior" to use a new component <permissions-admin-inherited> to render the permissions.

• [x] Create the component by copying and register it in the AccessControl module. This way the component becomes available when the module is loaded.

• [x] Change the component to be able to switch publicRead and publicWrite and to show a list () of users () (use the intercreativity home page as an example), and next to them show if they canRead, canEdit or canAdmin. Let an admin user change the permissions of other users.

• [x] Change the backend so that it returns the delegate-related information when returning the permissions of an object.

[pepoospina]

A stub with the change in the backend on access.services.ts

  async getPermissionsConfigOfElement(elementId: string, userId: string) {
    const accessConfig = await this.accessRepo.getAccessConfigOfElement(elementId, userId);
    if (!accessConfig.permissionsUid) throw new Error(`persmissions not found for element ${elementId}`);
    const permissions = this.getPermissionsConfig(accessConfig.permissionsUid);
    return {
      delegate: accessConfig.delegate,
      delegateTo: accessConfig.delegateTo,
      finDelegatedTo: accessConfig.finDelegatedTo,
      permissions: permissions
    }
  }