The implementation of this will be covered in #33534 (closed) after the discovery is complete.
Problem to solve
Currently, subgroups inherit in total the members from the parent group.
While it is possible to override the members access on subgroups (for example, give master access to someone on a subgroup who has developer on the parent group), it is not possible at the moment to remove access to members on subgroups (for example, in a confidential private group, allow only members from the parent group who have some admin status to see and enter the subgroup.
Intended users
Sidney (Systems Administrator)
Constraints
A "secret" group with no membership inheritance can't have subgroups. For example:
Top-level group
Subgroup A (inheritance, further nesting allowed)
Sub-subgroup B (inheritance, further nesting allowed)
Secret subgroup A (no inheritance, no further subgroups allowed)
Secret subgroup B (no inheritance, no further subgroups allowed)
Owners can always get inherited. If we toggle membership inheritance, there's a chance we leave Owners behind and could have a weird situation of an Owner-less group. To prevent that, allow Owners to always be inherited.
I would say that each subgroup should have the flag "inherit members".
I would also add this flag to the projects as well.
If enabled, the subgroup will inherit all the members from its direct parent group (note that direct parent can have its own members as well as some members inherited from its own parent, based on the flag setting in it)
If disabled, the subgroup will have empty list of members and user (owner or maintainer) should explicitly add group/project members.
Changing the parent's flag should not change or affect the flag of the child groups/projects.
A flag of the group/project should be "inherit members" which defines if that group inherits members from its parent or it starts with a blank list of members.
That said if we have group chain A -> B -> C and they have the following members (a1, a2), (b1), (c1) respectively and they all have the "inherit members" set to TRUE, the effective members would be:
A: a1, a2
B: a1, a2, b1
C: a1, a2, b1, c1
If admin changes the flag of group B to FALSE, the effective members would be:
A: a1, a2
B: b1
C: b1, c1
Note: The flag "inherit members" does not have any effect on the root-level group A, so this may be a disabled option for top-level (root) groups.
In my opinion, users in Group C should only inherit from Group B. I think this is more intuitive. It also makes more sense for the problem we want to solve, which is allowing the creation of hidden groups inside of a top-level group.
If Group B is the hidden group (preparing for a product launch that we don't want to leak), there may be lots of subgroups inside of it. I want to add the team to Group B and not have to add them to all of the sub-groups underneath it as well; if we inherit from all parent groups, I'd have to disable inheritance for every single sub-group and add every single member separately.
@jeremy@mksionek - Agreed here, Group C should only inherit from B. The first iteration can disable the ability to change inheritance from any downstream group if it makes it easier.
In your example this would mean Group C doesn't have the ability to change inheritance, it's always off. So would Group D and Group E, etc.
This is a good idea, but not as crucial as the inheritance of members.
If we want to have this feature, it would probably make sense to have the "Require all users in this group to setup Two-factor authentication" checkbox as 3-state checkbox:
checked - require 2FA
unchecked - 2FA not required
3rd state - inherit from parent's settings (the default option)
search page: in users scope, when a group is given, we search for users in ancestors, given group, and descendants of the given group. Does this behaviour should change?
I am not sure that I understood the questions correctly, but the following may be very handy:
When user defines a (sub)group or project members, a "search for a user" a search logic that populates the auto suggest box search results should be driven by additional flag. This new search flag would tell which set of users should be searched:
direct parent's members only (selected by default)
entire ancestor tree members
entire world (all gitlab.com users)
This option is very important because right now one can very easily select wrong (outside of the organisation) user with similar username and allow him/her the access to the non-public project.
Execution proposition: as this will require adding two paths of adding authorizations/checking authorizations etc, my proposition is to roll it out behind a feature flag in a really small MRs. One MR for all changes looking at the scope of changes will be unreviewable :(
I think we should 1) answer all questions, probably with UX involved 2) with all questions answered, break it down into smaller issues (one for settings, one for search, one for policies (very tricky) etc) 3) implement the issues one by one behind the feature flag 4) test it extensively 5) remove the feature flag.
Thanks, that's really helpful. I'm going to break down the issues as suggested and add them to &588 (closed). I'm also going to pull this out of %12.4 since it's clearly not achievable in this release.
Jeremy Watson (ex-GitLab)changed title from Optionally ignoring membership inheritance for subgroups to Optionally ignoring membership inheritance for subgroups: Discovery
changed title from Optionally ignoring membership inheritance for subgroups to Optionally ignoring membership inheritance for subgroups: Discovery
Regardless of how subgroup or project members are defined, an owner of the root-level group should be able to access all subgroups and projects as an administrator.
Owners always get inherited. If we toggle membership inheritance, there's a chance we leave Owners behind and could have a weird situation of an Owner-less group. To prevent that, allow Owners to always be inherited.
It's a priority for us. This issue represents the engineering discovery work. We'll create additional issues out of the spike and add them to the epic as required.
I'll estimate a product solution in %12.9, possibly %12.8.
Jeremy Watson (ex-GitLab)changed title from Optionally ignoring membership inheritance for subgroups: Discovery to Optionally ignoring membership inheritance for subgroups: Design and Discovery
changed title from Optionally ignoring membership inheritance for subgroups: Discovery to Optionally ignoring membership inheritance for subgroups: Design and Discovery