Rework the groups and inheritance part of the database?

[fflorent]

Describe the problem to be solved

I share here some aspects I feel it's hard to understand and to manage with the database:

• the Roles¹ are actually stored as Groups in the database, which can be confusing especially when we will actually implement groups management;
• the inheritance is not materialized in the database, except in groups of groups memberships, as described here;
• there are many joins especially through the groups to do to know "what access is granted to user X for document Y";
• we can end up having maaaany groups (for example it can be barrier to use Groups management through SCIM);
• the Resource memberships² is materialized in the Resources themselves but also in the group memberships for inheritance, which feel like a bit confusing and hard to manage due to the duplication;

Also if we want to introduce the groups management as a true concept for the end users:

• there is currently a limit of recursion for querying group memberships in the code, due to performance issues, which prevent group recursions (ie "group of groups");

Describe the solution you would like

I wonder if there exist some reasons for what I feel like a complexity.

I propose this rework (I may be wrong and I may face issues, this proposal is also meant for me to understand the subtleties behind the current implementation if it gets rejected):

You notice that:

• the "masks" properties for Resources (docs, workspaces and orgs) is meant for the addressing the "inherit access" field in the Users Management popup in the UI (it looks more intuitive );
• the acl_rules table is now a join table between the following tables:
  • the roles which stores an name (like "Owners") and the associated permissions (like what currently exists as acl_rules.permissions);
  • the users directly if the ACL is for a user, or the groups otherwise
  • the resource tables, so either: docs, workspaces or orgs
• the groups:
  • are only meant to store true groups (as it will be presented to the end users), not the roles anymore
  • there is room for groups managing other groups, that we may address as a further step
• the Resource membership is only materialized once (in resources)

Though I am not sure whether it will be more optimized for getting permissions through inheritance.

So do you think it could be relevant a rework of this kind?

Of course, I admit it would be an ambitious work. Still I feel like it might be worth the effort.

Footnotes

1. Owner, Editors, Viewers, ... ↩

2. Concept for telling something like: "doc X belongs to workspace Y" or "workspace Y belongs to org Z" ↩