Administration

Users and Groups

Adding people

Only an instance administrator creates an account on this screen, renames one, hands out or revokes a credential, or switches an account off. An admin of a nexus does not see the New account half of the form; they add people who already have an account to the nexuses they run. Accounts also arrive by the other routes listed further down, and a GitLab group sync is run by an admin of the nexus being synced.

Open Admin, then Members, then Add a person. Type a name and a username (the email address is optional), pick which credential to hand over (a one-time password to read out, an activation link to copy, or none yet), and click Create the account. You deliver the password or link however you already talk to the person.

If this instance sends email (set up under Admin, then Email), a person’s pane under Admin, then People & access also has Send password reset email. It mails them a one-time link to set a password, to the address on their account; the link never appears on your screen. The button is greyed out, with an (i) saying why, when the instance does not send email, when the account has no real address, when the account signs in through a directory or SSO and has no password here, when email and password sign-in is off, or when the account is deactivated.

Creating the account and granting access are two different acts. A new account gets a private nexus of its own, so the person has somewhere to write from their first sign-in, and reaches nothing SHARED until it is placed: open Admin, then Access, pick the person, and add them to the nexuses they belong in. Access is also where an account that already exists is given a nexus; a membership never creates an account.

Accounts are also created without this form: by the first-run Initial Setup screen (which mints the very first nexus and its administrator), by self-registration (switched on under Admin, then Authentication, or pinned by the ALLOW_REGISTRATION environment variable), by a directory connection at a person’s first sign-in or at a sync (set up by an instance administrator under Admin, then Authentication, then LDAP), or by a first SSO sign-in. See Authentication.

An account a directory creates is no exception to the rule above. It gets the private nexus every account gets and nothing else: a directory places nobody into a shared nexus and gives nobody a role. Place directory people the way you place anybody, under Admin, then People & Access: + Person, then Existing account, then their exact username or email address, a nexus and a role. See Placing directory people.

The member list

The list shows avatar, name, email, source, role, and join date.

Search filters on name, username and email (or a nexus name, which lists its roster).
Source chips filter to All, LOCAL, LDAP, or OAUTH, with a count on each.
Role chips filter to All, Owner, Admin, Member, or Guest.

Click a member’s role badge to change it inline. Click the X to remove them. Removal drops their access to that nexus. Their account and the pages they wrote stay put.

Roles

Roles are per nexus, not global.

Capability	Owner	Admin	Member	Guest
Full access to every space in the nexus	Yes	Yes	No	No
Add and remove members	Yes	Yes	No	No
Change member roles	Yes	Yes	No	No
Promote someone to Owner, or change another Owner’s role	Yes	No	No	No
Manage groups	Yes	Yes	No	No
Create, rename and delete labels and templates	Yes	Yes	Yes	No
View audit logs	Yes	Yes	No	No
Rename or delete the nexus	Yes	Yes	No	No
Access spaces	Per space permissions	Per space permissions	Per space permissions	Per space permissions

Two things belong to the instance rather than to any nexus, so no nexus role reaches them: directory (LDAP) connections and licensing. Only an instance administrator configures, tests or syncs a directory connection, or manages licence keys. A directory’s groups decide no nexus role either.

A guest reaches every space and page at View at most, whatever their permissions say: they can read and comment, but not edit. A guest cannot create spaces, labels or templates. Space and page permissions decide what a member or guest sees.

Groups

Open Admin, then Groups. Click New Group, give it a name and an optional description.

Select a group to manage it. Search for users under Members to add them. Only members of the group’s own nexus are offered. Removing someone from a group leaves their nexus access untouched.

Deleting a group removes any space permissions granted through it. Members keep their nexus access.

Space and page permissions

Grant access to a space from that space’s permissions dialog. You can grant to a user or a group, at one of three levels.

Level	Meaning
Full Access	View, edit, delete, and manage that space’s permissions.
Can Edit	View and edit pages.
Can View	Read only.

How the effective level is worked out:

Nexus owners and admins always get Full Access. Nothing else is consulted.
Otherwise, take the highest of the user’s direct grant and every grant from a group they belong to.
If the space is public and they are a nexus member with no explicit grant, they get Can View.
Private spaces with no grant give nothing.

Individual pages can override this. A page set to private visibility ignores space permissions entirely and only honours explicit page grants. Pages set to public or inherit fall back to the space.

Only nexus owners and admins can add or remove permissions.