Member

The link between a User and a project or group, carrying their access level.

Source

app/models/member.rb plus subclasses:

• ProjectMember
• GroupMember
• (EE) MemberRole for custom roles.

app/services/members/ and ee/app/services/members/ handle invite, accept, update, and remove flows.

Access levels

The Gitlab::Access constants:

• NO_ACCESS (0)
• MINIMAL_ACCESS (5)
• GUEST (10)
• PLANNER (15) — EE
• REPORTER (20)
• DEVELOPER (30)
• MAINTAINER (40)
• OWNER (50)
• ADMIN (60) — instance-level, not stored on member rows

GUEST < PLANNER < REPORTER < DEVELOPER < MAINTAINER < OWNER. Access is the maximum across all sources (direct, group inheritance, custom role).

Direct vs inherited members

A user becomes a project member by:

• Direct invite (ProjectMember).
• Group inheritance (group members get matching access on the project).
• Sub-group inheritance (sub-group members inherit ancestor group access).
• Project sharing with another group (ProjectGroupLink).

Effective access is computed by Member#access_level_for and cached per request.

Custom roles (EE)

MemberRole (ee/app/models/member_role.rb) declares fine-grained permissions on top of a base access level. Custom roles let admins build "auditor + can_admin_compliance_framework" without modifying every project.

Pending invites

Invites can be issued to email addresses without a registered user (Member#invite_token). When the recipient signs up, the invite resolves to a real user.

Access requests

AccessRequest is a Member row in pending state. Group/project owners approve or reject from the members UI.

Audit

EE logs every member-level change to audit_events and (optionally) streams to external SIEM via audit_events_streaming_destination.

Related

• User, Group, Project.
• Authorization.