Proposal: Reconceptualize current inheritance model

Problem

At the moment we have various mechanism for a user to become part of a group or project. These mechanisms are:

• The user is directly added to a group/project
• The user becomes a member through inheritance. They are a direct member of a group higher up in the hierarchy, and their membership inherits into the underlying groups/projects.
• The user becomes a member via a shared group
• The user is a member of a project contained within the group

Depending on whether a user is a direct or inherited member, they may or may not enjoy certain functionalities of the group/project they became part of.

Only direct members can:

• Be used to generate boards
• Be shared into another group via group sharing
  • Note: Sharing into a project includes Direct and Inherited members

Current Benefits

• Users have made the current model work for them

Current Disadvantages

• User management is difficult to understand for users
• Inheritance of group members into subgroups is forced
  • Members that need access to high levels are members in every group/project below
  • Membership at lower levels does reflect actual membership of the group/project
    • Requires filtering by direct to see actual members
    • Mentioning includes unintended members
  • Users see a lot of groups and projects they have little to do with in the list of groups and projects
• Removal of inherited membership can only be done in the the parent (source) group
  • This would also require removal of access to the parent group
• Requires understanding of the nuances between Direct and inherited (sharing, generate boards)
• Project members have parent groups listed in their groups, but are not listed as members of those groups

Proposal

We simplify the concept of membership. In this new model, we distinguish between Members and Access.

• Members are what we call 'direct members' today
• Access is what we call 'inherited members', 'indirect members' and 'inherited indirect members' today
• Members have access to all subgroups and projects (example: A has access to Subgroup 1)
  • Permissions are the same in subgroups and projects as in the group they are a member of (unless otherwise restricted, see below)
• When a group is invited into a group/project, the members of the invited group become members of that group/project (example: D is a member of Sharegroup 3 that is invited to Subgroup 2 and therefore becomes a member)
• Access is not shared (example: E does not have access to Subgroup 2)
• Group/projects can allow those with access the option to join the group/project as members
  • Might want to restrict this to projects to avoid sharing of joined members
  • Might not be needed at all

Benefits

• Admins need some sort of cascading access model to avoid constant and frequent access requests
• There are situations where admins want to break from that model and need more specific control
• Admins need to balance predictable/understandable with flexibility where they need it
• Default permission cascades down predictably and without the need for admin intervention
• Permission can be restricted where needed
• Permission can be increased where needed
• Separating Members and Access in this way is a step towards building Teams

Disadvantages

• Some changes might be breaking changes for customers

Implementation

Removing inherited members and replacing them with access is mostly a UI/documentation change in that access is basically Inherited membership. We would need to change:

• UI references to Direct and Inherited - Remove those references
  • Project members page > Members
    • Remove mention of Direct member from Source column
    • Members filter refers to Members and Access instead of Membership = Direct and Membership = Indirect
  • Project members page > Groups
    • Remove mention of Direct member from Source column
    • Members filter refers to Members and Access instead of Membership = Direct and Membership = Indirect
  • Group members page > Members
    • Remove mention of Direct member from Source column
    • Members filter refers to Members and Access instead of Membership = Direct and Membership = Indirect
  • Admin Area > Users ?
• UI workflow improvements
  • https://gitlab.com/dashboard/projects > Your projects shows projects where user is a Member by default
  • https://gitlab.com/dashboard/groups > Your groups shows groups where user is a Member by default
  • User profile > Groups lists groups where user is a Member by default
• Docs references to Direct, Inherited, Indirectly Inherited and Indirect - Replace those with Members and Access
  • Manage groups page
  • Share projects with other groups page
  • Subgroups page
  • Members of a project page
  • Other pages?

Possible follow-up implementations

• Joining may not be necessary, or could be a future iteration
• Group/projects can be set to "members only" to prevent inherited access.
  • Those who would have had inherited access are treated as any other user that did not have access
  • This would prevent joining
  • Would need to account for admins somehow (TBD)
• Change sharing of group members from inherited to Direct membership only (this may be big)