How to add users ONLY to top-level group?

[felsgaertner]

Hi, as GitLab inherits permissions downwards to descendant groups, it is sufficient to only add members to one group.

GitLabForm adds users to all descendant groups, though it is not required. How do I prevent this?

So if have these groups:

A
A/1
A/B
A/C
A/C/2

and add members to the configuration:

projects_and_groups:
  '*':
    group_members:
      users:
        vip:
          access_level: owner

I end up with user "vip" assigned to all groups. This example has just A as root, but there could by more children next to B and C.

I just want the user assigned to group A.

[amimas]

GitLab inherits permissions downwards to descendant groups, it is sufficient to only add members to one group.

Maybe I'm just mis-interpreting this. But just to clarify, subgroups will always inherit members configured in the parent group. That's how Gitlab works.

I just want the user assigned to group A.

In your example all the subgroups under A will inherit it.

[amimas]

You could configure members on the 2nd level. For example:

A/1 A/B A/C

You can configure the "vip" user to only A/1.

There's also a inherit: false config in gitlabform that can be used for breaking config inheritance from higher level. Checkout the gitlabform docs.

[felsgaertner]

GitLab inherits permissions downwards to descendant groups, it is sufficient to only add members to one group.

Maybe I'm just mis-interpreting this. But just to clarify, subgroups will always inherit members configured in the parent group. That's how Gitlab works.

I just want the user assigned to group A.

In your example all the subgroups under A will inherit it.

Yes, that's how GitLab works. But gitlabform assigned the members to the subgroups as well - even though it is not needed and ignored by gitlab.

[felsgaertner]

You could configure members on the 2nd level. For example:

A/1 A/B A/C

You can configure the "vip" user to only A/1.

There's also a inherit: false config in gitlabform that can be used for breaking config inheritance from higher level. Checkout the gitlabform docs.

Yes, I know. But as I might have more than only these groups, there could be more subgroups, I do not want to configure each one repeatedly.

[adam-moss]

Since you can't break inheritance on users we assign them at the project level not on groups. It has taken a while but we're almost free of group-level users other than GATs.

Also, there are a number of issues if you do rely on inheritance. Approval rules is an obvious one, but there are some other real oddities, especially if the user has "Owner" access.

[amimas]

Since you can't break inheritance on users we assign them at the project level not on groups. It has taken a while but we're almost free of group-level users other than GATs.

Same here. Although we had to add users at the group level in few cases so that users could take advantage of creating Epics at the group level.

There's an item in GitLab's backlog for potentially breaking membership inheritance.

https://gitlab.com/gitlab-org/gitlab/-/issues/383662

@gdubicki - Noticed you've added the feature request label to it. Wondering what that is on gitlabform's side? Add option so that members are not added to the subgroups? Does it matter?

[felsgaertner]

Hi,

I tried to solve this using a config like this:

projects_and_groups:
  A:
    group_members:
      users:
        vip:
          access_level: owner
  A/*:
    group_members: {} # do not change anything here

Could that work? Or do I need an "inherit: false" as well?

[amimas]

The inherit key is a gitlabform feature for controlling the final/effective config that is generated for gitlabform.

I don't think the above config will work. Currently to configure settings/members for a group, it'll need to be under A/* key.

For above config sample to work, I think it will have to be a major release of gitlabform with config syntax change. One challenge is something like A/B: key. Here it's not clear whether B is a group or a project. I guess gitlabform can do extra processing to figure that out but from a config readability, it might not be intuitive.