Context

Following #1199, this PR proposes to implement the /Groups Endpoint.

As an IT asset administrator, I can create groups for my users using a centralized solution (an Identity Provider) so they can easily access to the resources. But these groups and memberships are not pushed to Grist as of today. The administrator is either offered to remove access entirely to Grist, or access to Grist and modify the permissions on the resources. Most of all, as Teams are not represented through the UI, it can be a quite painful task.

Proposed solution

SCIM is a standard proposed by the IETF through RFC7644 and RFC7643 which aims to through a simple Rest API provide solution for the above use cases.

Here is the abstract of the RFC7644 which introduces SCIM:

The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service.
Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.

This PR provides a complement to the now existing /scim/v2/Users endpoint (documented here):

Currently only the Roles were represented in the "groups" table. To achieve this distinction, this PR also introduces a "type" column, which only accept team or role values.

This PR provides the implementation of SCIM for Groups (aka Teams), and supports:

• All the basic actions for Groups (POST /Groups/, PUT /Groups/:id, GET /Groups/, GET /Groups/:id and DELETE /Groups/:id).
• The POST /Bulk endpoint
• The POST /Groups/.search by using the Filters (actually to use them, you must have to fetch all the Resources from the DB, the filtering is done in JS, which is probably fine for small projects, I would just be cautious when using big databases + an ORM);
• The PATCH /Groups/:id endpoint! It reads a resource using the egress method, applies the asked changes, and calls the ingress method to update the record ;
• The pagination

The endpoint for /Roles are nearly the same, though:

• Creation (trough POST) and the deletion are not allowed;
• We can only update the memberships, which is helpful to assign a role to users or teams;
• And the endpoint also return the resource ID associated to the role through the orgId, workspaceId or docId readonly attributes.

As in #1199, I take advantage of these two libraries: scimmy and scimmy-routers.

👀 Known limitations

1. You cannot add a group as a member of a Resouce Users group, due to the fact that the depth for groups are limited to 4.
2. The groups are not displayed in the Users Management popup for now. This may be a bit confusing.

⛹️ Play with this endpoint

This is a step-by-step tutorial to play with this new endpoint:
https://gist.github.com/fflorent/dd11a15e424ab4828f679ab038eea764

Related issues

Fixes #870

Has this been tested?

• 👍 yes, I added tests to the test suite
• 💭 no, because this PR is a draft and still needs work
• 🙅 no, because this is not relevant here
• 🙋 no, because I need help