Users and roles
These are the accounts that sign in to the console. They are separate from the Odoo users inside a database, which are managed per database.
The four roles
| Role | Can |
|---|---|
| Administrator | Everything, including users, licenses and server-level operations |
| Read-only administrator | See everything an administrator can, change nothing |
| Operator | Day-to-day operations on the instances they are scoped to |
| Viewer | Read-only, on the instances they are scoped to |
The first account created during setup is an Administrator and is protected: it cannot later be deleted, disabled or demoted. Locking every administrator out of the console is the one failure with no remedy from inside the console, so the product refuses to allow it.
When the license changes
Roles other than Administrator are a licensed feature. When the license stops carrying it, every account holding another role - Read-only administrator, Operator, Viewer - is disabled, keeping its role, its instances and its password; Administrators are untouched. A license with fewer console accounts disables the newest accounts above the limit, always keeping the account created at setup and one Administrator. Both come back by themselves when a license allows them, and the Users page says which accounts the license disabled. Until then they cannot be enabled by hand: enabling an account with a role other than Administrator needs a license that carries roles, and enabling any account needs a free console account under the license's limit. See When the license changes.
Instance scoping
Operators and Viewers can be limited to particular instances. This is what makes a shared console workable for a hosting company: a customer's operator sees their own instances and nothing else. The directory and file pickers show such an Operator only those instances' own directories - their files, their backups and the uploads they made themselves; any other folder on the server is refused, and one outside them must be chosen by an Administrator.
Scoping is by instance id, and it applies to what the API returns, not only to what the UI draws.
Role enforcement happens on the API using the user identity the console forwards. The API key is the machine boundary: anything holding a valid API key is a trusted caller, and roles refine what that caller may do on behalf of a user.
Treat the API key as equivalent to administrator access, and do not hand it to someone you only meant to give Viewer.
Managing users
Users in the console, administrators only. The list shows every account with its display name, role, status (enabled, locked or disabled), second factor, last sign-in and the instances it reaches; the column picker adds the e-mail address, the last sign-in address, the open sessions, the environments and when the account was made. The same list is on the GeoIP and Fail2Ban consoles.
Add account and the pencil on a row open the same editor under the list:
| Field | What it sets |
|---|---|
| User name | The name the account signs in with. Renaming an account signs it out everywhere |
| Display name | The name the top bar shows; the person can change it on My Account |
| E-mail address | Where its security notifications go; empty sends none |
| Role | One of the four roles. Roles other than Administrator need a license with role-based access |
| Password (new account) / Enabled | The first password; whether it can sign in |
| Development access | The workspace profile that lets it open the browser editor, when the server has any |
| Reach | For a Viewer or an Operator: the environments and instances it may see |
| Multi-factor policy | Require makes it set up an authenticator app at its next sign-in |
| Sign-in lockout | Whether it is locked, with Unlock |
Save applies the shared fields first and then the reach and development access, each as a job whose outcome the page reports. The multi-factor policy and Unlock act at once, on their own.
Under Security the editor sets a new password, takes away an authenticator app (for a person who lost their phone and their recovery codes), signs the account out everywhere and deletes it. The built-in administrator cannot be demoted, disabled or deleted, and nobody can delete their own account.
Break-glass recovery
When nobody can sign in, the CLI repairs accounts:
$ ohm user list$ ohm user password-reset admin$ ohm user totp-disable admin$ ohm user unlock adminRun on the server with sudo, these are the way back in when MFA is lost or an account is locked out -
which is why shell access to the host has to be protected at least as carefully as the console
itself. Run against another server with --server and an issued API key, only ohm user list
works: the commands that change an account are refused there, so run them on that server itself, or
change the account on its Users page. See
What an issued key cannot do.
A repair or update of the server (ohm install) does not unlock an account: when admin is locked
or disabled, its hand-off names ohm user unlock admin instead.
If even that fails, ohm install --rotate-secrets prints a new admin password in its hand-off and
clears the TOTP. See Repairing an installation.