CRUD models/API for user groups

[tcompa]

Scope boundaries:

1. How to use those groups for access control will be discussed elsewhere
2. We will not allow (for the moment) operations that can remove access after it was granted (e.g. removing a user from a group, or deleting a group). We will revisit this assumption, since it has the downside of having an ever-growing size of the user/groups relationships and group table.
3. Group names are available to all users, but list of group members is only visible to superuser. The current user can know their own groups.

Here is the first draft of new API

New user-group endpoints

• POST /auth/groups/
  • creates a new group
  • request body: name and user_ids: list[int] (empty list is accepted)
  • fails with 404 if there is any non-matching user ID
  • superuser-only
• GET /auth/group/{id}/
  • returns full info on an existing group (including members)
  • superuser-only
• PATCH /auth/group/{id}/
  • request body: new_user_ids: list[int] (empty list is accepted)
  • For the moment, changing the group name is not allowed
  • superuser-only
• DELETE /auth/group/{id}/
  • responds "405 Method Not Allowed" (see scope limitation 2 above)
  • superuser-only
• GET /auth/groups/
  • returns list of groups, which includes their members
  • superuser-only
• GET /auth/group-names/
  • returns a list of existing group names (not their members)
  • accessible to all active users

Changes to the existing endpoints

• GET /auth/users/

  • it returns list of users, which should also list their groups
  • superuser-only

• POST /auth/register/

  • it should include a new group_ids: list[int] field (empty list is accepted)
    • in the webclient, this list can be populated by picking some groups from the broadly-accessible list of group names
  • user is also always added to a default group (e.g. named "all", or "all-users")
  • superuser-only

• PATCH /auth/user/{id}/

  • the response should include a new group_ids: list[int] field (empty list is accepted)
  • this endpoint is not used to modify groups, since you would use PATCH /auth/group/{id}
  • superuser-only

• GET /auth/current-user/

  • if ?group_names=true, then response includes a group_names attribute
  • each registered user can call this

• PATCH /auth/current-user/

  • response always includes a group_names attribute
  • there is no way for the user to modify their own groups
  • each registered user can call this

[jluethi]

We will not allow (for the moment) operations that can remove access after it was granted (e.g. removing a user from a group, or deleting a group). We will revisit this assumption, since it has the downside of having an ever-growing size of the user/groups relationships and group table.

Agreed that this is the initial goal. But thinking of this on a larger server, we will eventually need to support removing someone from a group (even just "I added the wrong person to a group") or even deleting groups (later)