We have the same behaviour when this option is set to true applied according to our 9.1.4-ee platform.
The owner of an A/B/C group can:
create subgroups from A/B/C level
create entire group trees from top-level
He cannot:
create subgroups from A, B, A/B/D levels
It seems that the original intent (allow delegation to group owners in an organized manner) is somethat broken if these owners can create a parallel world outside the scope they were supposed to If so, this should be considered as a bug, not a feature request, or did I miss something?
My point is this : maintain a higher group structure allowed to admin team only, and delegate the ability to create subgroups within lower levels to their respective owners.
Actually, a user having an ownership role in the A/B/C group hierarchy needs the "can greate group" attribute on his account to do so, as we noticed on our platform.
He cannot create subgroups in A, A/B nor A/B/D groups directly as he is not owner of these structures, which is good.
The drawback is that this user, thanks to the "can create group" attribute, could create an entire new group structure from top-level, something like myA/B/D or anything else that was unintended.
In an organisation with hundreds of groups mixing organisational, transversal and contractor teams, we can simply not let privilegied users act outside their scope. So, unless there is a way to prevent these flaws we will not be able to allow the subgroups creation for our end users, which will have a negative impact on our "self-service, self-managed" adoption model to promote Gitlab within our department.
I'm in/of the same position as @sedat.guclu. We want to delegate group and subgroup ownership without allowing top-level groups. We're fine with the current permission system for top-level groups (disable by default and enable on a per-user basis).
Another here.
We are also in the same situation as Sedat. Our users (group owners) are desperately wishing to have sub-group creation privilege which we currently prevent due to this very reason.
Hi,
We're in the same situation in my company, where I manage the GitLab instance: we cannot permit users to create top-level groups, but would like them to be able to create subgroups in top-level groups they own.
Note that we are NOT adding new configuration to gitlab.yml/gitlab.rb, so this will need to go into the Admin Area. We should move default_can_create_group there too.
@DouweM@mydigitalself just want to make sure we're on the same page regarding the requirements here. Currently and admin user can edit a regular user and enable/disable the ability to create groups:
In order to allow users to create subgroups when this flag is disabled we should:
Add a new user setting for subgroups similar to the one used for creating groups.
Only users who are Owners or Masters will be able to create subgroups when this flag is enabled.
Can you please let me know if these are the exact requirements?
@rdavila 1 is correct. 2 is correct too, but that's already checked as part of the :create_subgroup ability. The main ability-level would be having create_subgroup check a new user.can_create_subgroup, instead of the current user.can_create_group.
Also note that on top of that new User setting, there should be a new Application setting to set the default for can_create_subgroup, just like we currently have gitlab_rails['gitlab_default_can_create_group'] = false in gitlab.rb/gitlab.yml.
All of that sounds relatively complex. I think it would be acceptable to simply treat user.can_create_group and gitlab_rails['gitlab_default_can_create_group'] as if they said can_create_top_level_group, so we can always allowing subgroup creation. From what I see in this issue, that seems like it would be fine. The main concern is with top-level groups.
@mydigitalself My suggestion is actually to not add a new server-wide setting, and to treat the current "Can create group" setting as "Can create top-level group" instead of "Can create top-level or subgroup". That would be far easier to implement, and seems to solve the problems of everyone in this thread.
@DouweM I think people may still want more control, it's hard to say. If we have as per the description a server-wide ability for people to create subgroups, people can choose this configuration.
I'm happy for it to be can_create_subgroup as default to true, and if any strict sites want to disable that, they can change it to false.
@mydigitalself I worry about adding a new configuration option no one may care about. Subgroup creation will be limited to group owners anyway, so that’s already a very limited group that hopefully actually owns the group their own.
I suggest shipping as described (simply changing the behavior of can_create_group), and introducing the ability to disable subgroup creation across the board if people complain.
@rdavila I think what we can do is allow subgroup creation by owners and masters of a group. If that becomes problematic, we can always put in a further option to disable that.
The suggestion by @mydigitalself to allow subgroup creation by owners and masters of a group would certainly solve the issue my organization is facing. We'd like to limit who can create top-level group but permit any group owner or master to create as many sub-groups as they would like.
@frankhinek, I do not like the idea of masters creating sub-groups. At least not if such an action would make them an owner of the sub-group. That sort of privilege promotion could have negative effects, particularly for integrations that rely on GitLab's permission model. I would say this privilege should be restricted to owners.
@mmaguigan-dti Upon further reflection, I have to agree. If you look at the Group members permissions section of the Permissions doconly an Owner can create, edit, and remove subgroups.
@rdavila It would seem the associated Merge Request !14046 (merged) should only effect Owners. Otherwise, this would introduce a global change to the permissions structure in GitLab.