Users, groups and permissions

This section is intended for system administrators and project/repository owners with the required permissions.

Creating a user

Open Administration → Users → New user and enter:

• username;
• email;
• display name;
• a temporary password or a server-generated password;
• language and theme;
• whether the account is a system administrator.

A new user must change a temporary password when the system marks it as required.

Account states

• Active — normal access;
• Pending activation / approval — waiting for action;
• Disabled — temporarily disabled;
• Locked — blocked;
• Archived — removed from normal use.

A state change requires a reason and is audited.

Groups

Use groups when several people need the same permissions.

Example:

Group code: ERP-DEVELOPERS
Name: ERP Developers
Members: maria, ivan, automation-ci

Grant the group a Developer role instead of assigning every user separately.

Project role

A project role is inherited by repositories, subject to lower-level policy restrictions.

Example: ERP-DEVELOPERS receives Developer on project ERP.

Repository role

Use a repository role when a person should work only in one repository.

Example: a technical writer receives Maintainer on Documentation but no commit permission on Server.

Path permission

A path permission restricts access to a folder or file.

Example:

Principal: group EXTERNAL-AUDITORS
Role: Reader
Path: /evidence/2026
Apply to descendants: Yes

Good practices

• Grant the minimum required access.
• Use groups for teams.
• Do not use a system-administrator account for daily commits.
• Record a clear reason for revoke, force release, disable and archive operations.
• Periodically review the audit trail and inactive accounts.