Skip to content

Members

These sections are for managing the users and groups that are members of a projects and groups.

Project members

There are 4 keys that can be set in the members section:

  • groups - to make other groups members of a given group. Here the key names are group paths and values are as described in the share project with a group endpoint of the Projects API,
  • users - to add single users. Here the key names are usernames and the values are as described in the add member to a group or project endpoint of the Group and project members API,
  • enforce - if set to true then this project will have ONLY the users and groups listed in the configuration as the direct members (so this setting will NOT affect the members inherited f.e. from a group that contains this project); default is false.
  • keep_bots - if set to true then any existing project members that are bots will not be removed regardless of the enforce setting; default is false.

Note: there has to be at least 1 user/group with "owner" access level per project - it's required by GitLab.

Example:

projects_and_groups:
  group_1/project_1:
    members:
      groups:
        my-group:
          group_access: maintainer
        my-other-group/subgroup:
          group_access: maintainer
      users:
        my-user:
          access_level: maintainer
          expires_at: 2025-09-26
      enforce: true
      keep_bots: true

Custom Roles (GitLab Ultimate Only)

Assigning of Custom Roles to Project members is supported within GitLabForm configuration.

member_role parameter can be supplied as either the name or id.

Support is provided for both SaaS and Self-Managed/Dedicated deployments of GitLab; GitLabForm will determine which Member Roles API to query

Warning

  • user access_level MUST still be supplied and MUST match the base_access_level of the custom role
projects_and_groups:
  group_1/project_1:
    members:
      users:
        my-user:
          access_level: maintainer
          member_role: 2
          expires_at: 2025-09-26
      enforce: true
      keep_bots: true
projects_and_groups:
  group_1/project_1:
    members:
      users:
        my-user:
          access_level: maintainer
          member_role: Limited_Maintainer
          expires_at: 2025-09-26
      enforce: true
      keep_bots: true

Group members

There are 4 keys that can be set in the group_members section:

Note: there has to be at least 1 user/group with "owner" access level per group - it's required by GitLab.

Example:

projects_and_groups:
  group_1/*:
    group_members:
      groups:
        another-group:
          group_access: no access
      users:
        my-user:
          access_level: owner
      enforce: true
      keep_bots: false

Custom Roles (GitLab Ultimate Only)

Assigning of Custom Roles to group_members is supported within GitLabForm configuration.

member_role parameter can be supplied as either the name or id.

Support is provided for both SaaS and Self-Managed/Dedicated deployments of GitLab; GitLabForm will determine which Member Roles API to query

Warning

  • user access_level MUST still be supplied and MUST match the base_access_level of the custom role
projects_and_groups:
group_1/*:
    group_members:
      groups:
        another-group:
          group_access: no access
      users:
        my-user:
          access_level: owner
          member_role: 2
      enforce: true
      keep_bots: false
projects_and_groups:
group_1/*:
    group_members:
      groups:
        another-group:
          group_access: no access
      users:
        my-user:
          access_level: owner
          member_role: Dev_ReadOnly
      enforce: true
      keep_bots: false