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 totrue
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 isfalse
.keep_bots
- if set totrue
then any existing project members that are bots will not be removed regardless of theenforce
setting; default isfalse
.
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:
groups
- to make other groups members of a given group. Here the key names are group paths and values are as described in the create a link to share a group with another group endpoint of the Groups 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 totrue
then removing a user or group from this config will also remove them from the group (so this setting will NOT affect the members inherited f.e. from a group that contains this group); default isfalse
.keep_bots
- if set totrue
then any existing group members that are bots will not be removed regardless of theenforce
setting; default isfalse
.
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