Members and their roles

The Members screen is the only place where someone is brought into, taken out of or requalified in a workspace. It touches nothing else: neither GitLab, nor the branches, nor the deployments. You reach it through the “Menu” button of a workspace bar, “Members…” entry, which only appears for managers and administrators.

The Members screen. A revoked member has their name struck through; an invitation without an account shows the address alone.

Drag to pan the screenshot

Who can ManagerAdministrator

The screen is open to managers and administrators. Its actions are not: a manager does not touch an administrator, and cannot appoint one. It is the only difference between a developer and a manager: the developer does not see this screen.

Reading the table

The search and three filters (status, role, last activity with “Active in the last 7, 30, 90 days” or “Never active”) narrow the list; “Reset” clears them. Sorting is by creation date, first and last name, or last activity. Everything lives in the URL: a shared link opens the same reading.

The three statuses

Bringing someone in

The two header buttons, “Add…” and “Invite…”, open the same dialog; the one you clicked only decides the open tab. Same role to choose, two sources of recipients.

The dialog. The right column shows what the selected role allows and what it refuses.

Drag to pan the screenshot

1. Choose registered users

   The “Registered users” tab lists the Deployer accounts that are not members yet, with a search. Tick as many as needed. They receive a notification email and can access the workspace right away.

   

2. Or invite by email

   The “Email invitation” tab takes addresses as chips: Enter, comma or Tab validate the current address. An invalid address stays shown in red and blocks validation. An address that already has an account becomes an active member; an unknown address receives a “create your account” email and appears as “Invited”. Both tabs keep their selection; a counter on the inactive tab recalls what is waiting there.

   

3. Choose the role

   One role for the whole batch, “Developer” by default: the common case, and the narrowest of the roles that deploy. The right column says what the role allows and what it refuses. A manager does not see the “Administrator” card.

   

4. Confirm

   “Add N members” or “Invite N members”. Those who were already members are skipped, without error; the notification says so (“3 members added, 1 skipped”).

   

Acting on a member

The menu at the end of a row depends on the status and on your rights.

• Edit… opens the same two-column dialog, where only the role changes: neither the email, nor the status, nor the identity.
• Revoke…, on an active member: they lose access, stay in the list as “Inactive”, and can be reactivated.
• Activate…, on an inactive member.
• Remove… deletes the row. For an active member, the confirmation asks to retype their email: it is a current access that disappears. An invitation or an already inactive member are removed without it.

What each role allows

The table the dialog shows, capability by capability. Roles go from the narrowest to the widest, and each one adds to the previous.

Two rows only appear where their module runs: validating merge requests follows the Features screen, rebuilding the assembled branch follows the Assembly module. In a workspace that has switched Features off, the product owner can no longer validate; the release notes remain.

Who can Installation administrator

Above the workspace roles, the installation administrator manages the accounts themselves (“Administration” menu, “Users…” entry: global role, deletion, address validation), sees every workspace and can enter any of them as an administrator, without an invitation. That is the recourse when a workspace no longer has a reachable administrator.