Roles (permissions) & access management for groups & projects vs. teams & workspaces (& permission-groups)

Proposal

Make User Management easier.

  • Make a Group Type used only for grouping accounts, e.g. Teams.

  • Make a Group Type used only for grouping projects, e.g. Workspaces.

  • Make a Group Type used only for setting minimum roles, e.g. PermissionsGroup.

  • Allow sharing a Group with a Project.

This one i do not know if it is just something i am missing in how to work with gitlab, but:

  • Allow for a Group(A) that is shared with another Group(B), to share the direct members of its(A) shared Groups(C,D) with that Group(B)

    So: sharing direct members of C&D with B, by sharing A with B.

    That is: a Developers PermissionsGroup with a RD-Dept Team can be assigned to a RD-Projects Workspace, setting the minimal role for RD-Dept Team its members to the role set in Developers PermissionsGroup.

    That is: give all members of RD-Dept Team a Developer Role in groups and projects underneath that RD-Projects Workspace

Right now i worked this out by assigning accounts to several groups as direct members, which makes user management more difficult than i would like it to be. (think about an account switching to another team or an account being removed, that should be just one page that shows the consequences of the action)

This setup allows me to assign a team with certain permissions to a group, while keeping fine-grained control.

Screenshot_from_2023-03-03_19-40-27

/acme/ is the main organization, having only a very small set of accounts as members, the company administrator(s).

/acme/groupings/ is the group that has permissions-/role-management, containing user-groups grouped by their roles.

/acme/projects/ is for ACME its projects, much like the current root of a self-managed gitlab.

/acme/teams/RD/ is for that team (RD) its specific repositories, where they can do stuff only they care about, with perhaps only one project as 'business-card' to the rest of ACME.

/acme(/internal)/issues/ since a group cannot be assigned-to/shared-with a project, this organization-wide project (without repository etc.) had to be in a subgroup, so a group could be assigned to that subgroup of the main group, making the project inherit the groups shared with that subgroup while allowing the main group to keep a minimal set of members.

A team could be a group that has direct members only, without (concern of) roles.

A permissions-group could be a group that has direct members & teams, overriding the roles to a minimum-role.

A workspace could be a group that has projects, and shared group-members (direct or through team-group or permission-group), optionally having sub-groups/sub-workspaces.

Background

To me, access & permission has more to do with not being overloaded with more than what i am using gitlab for at that moment.

Say i have several "hats", doing design, development & management. I would like to be able to mix & match those "hats", sets of permissions or "profiles".

Toggling a profile on/off should make gitlab give me different suggestions for autocompletion, and show other projects/groups.

Maybe related: &4035 (closed) & &3191 , although those seem to be premium-tier`ed.