gitlabform: Can't manage members of top-level group

Describe the bug

I would like to manage the members of our top-level groups. e.g. /infrastructure I’m not able to write the correct config.yml for this task. I have tried several variants.

Variant 1: Here the user was only assigned to all subgroups of /infrastructure. However, not to the actual top-level group.

config_version: 3

projects_and_groups:
  "infrastructure/*":
    group_members:
      users:
        user1:
          access_level: owner

Variant 2: An error was issued here for a subgroup of /infrastructure. Error: The inheritance-break flag set in “infrastructure/subgroup” under key “users” is invalid

config_version: 3

projects_and_groups:
  "infrastructure/*":
    group_members:
      users:
        inherit: false
        user1:
          access_level: owner

Variant 3: No error was output here. However, no change was made either.

config_version: 3

projects_and_groups:
  "infrastructure":
    group_members:
      users:
        user1:
          access_level: owner

Could you please help me to find the correct configuration?

GitLabForm version

3.4.0rc1

GitLab version

14.9.4-ee

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 16 (7 by maintainers)

Commits related to this issue

For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to gitlabform/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
For now usernames are treated as case-sensitive although they should not be, as in GitLab they are not. (You cannot have 2 users in a GitLab instances for which the username differs only in the case.... — committed to J4Numbers/gitlabform by gdubicki a year ago
fix(members): ensure group and project users are case-insensitive (#556) This change allows group or project memberships to be case insensitive when referring to user names. You cannot have 2 users... — committed to tmeijn/gitlabform by J4Numbers 10 months ago

Most upvoted comments

I like the structure but I’m not sure if we should spend a lot of time on this considering that GitLab is working on moving away from projects and groups to namespaces by the end of 2023, i.e. GitLab will merge projects and groups into a new entity.

See e.g.: https://gitlab.com/groups/gitlab-org/-/epics/9090

jimisola on Feb 13, 2023

Lower case usernames don’t work

It seems that we need to make the app case-insensitive for usernames then, like we already do for project and group names.

I think it would be generally better to split the keyword projects_and_groups into projects and groups. Probably it would be easier to distinguish in the code which API has to be addressed. Also it would be clearer how to handle the * wildcard and the direct group names. In addition, it fits well with the existing two keywords skip_projects and skip_groups. This breaking change might be good for config version 4.

Interesting take.

Could you please go ahead a propose a syntax f.e. to provide settings:

to a group entity and its subgroups/projects,
to a group entity but NOT its subgroups/projects,
ONLY to the group’s subgroups/projects, ?

gdubicki on Jan 14, 2023

Hi @escalate! Thanks for the detailed question.

Your problem seems to be the opposite of what was asked for in https://github.com/gitlabform/gitlabform/issues/434#issuecomment-1361247072 - there a user wanted to manage some settings only for a group, but not it’s subgroups, while you want to manage subgroups, but not the group.

Unfortunately this is not yet supported but if we come up with a backward-compatible way to implement it, the chances for getting it added relatively soon are higher.

How about we do this:

projects_and_groups:
  "infrastructure": # settings for the "infrastructure" group, but NOT its projects or subgroups

and

projects_and_groups:
  "infrastructure/**": # settings for the projects and the subgroups of "infrastructure" but NOT that group itself

…while keeping the existing:

projects_and_groups:
  "infrastructure/*": # settings for the "infrastructure" group AND its subgroups

…and…:

projects_and_groups:
  "infrastructure/project": # settings for the "infrastructure/project" project

Does this make sense to you? cc @amimas @jimisola

gdubicki on Dec 29, 2022