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 totruethen 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 totruethen any existing project members that are bots will not be removed regardless of theenforcesetting; 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_levelMUST 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 totruethen 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 totruethen any existing group members that are bots will not be removed regardless of theenforcesetting; 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_levelMUST 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