Roles and Permissions

One Role on Your Node

Every administrator on your node holds the same role, operator_admin. It administers this server: users, sessions, login history, blocked attempts, organisations, vaults, notifications and logs.

There is a second role, held by Trusted Codes centrally, which owns the federation, entitlement and commercial controls. It is not used on your node, and there is no way to reach it from here. tc-operator add-admin is fixed to operator_admin and can never confer the central role. The boundary is checked on the server on every request, not merely hidden in the console.

The honest limit: this constrains the staff you delegate to, not you. You own the Postgres on your own box.

What the Server Refuses

Some areas are denied to operator_admin and are hidden from the sidebar altogether: plans, entitlements, system parameters and feature flags, AI prompts, the marketing screens, the content screens, the analytics dashboards, and the federated-server management pages. Opening one of those addresses directly gives you a page reading Not available — this area is managed centrally.

That is by design. The entitlement ceiling your node runs under is granted centrally, and you administer your members inside it. You cannot raise it from your own console.

Controls That Are on Screen and Will Still Refuse

The sidebar filter hides whole screens. It does not hide individual buttons inside a screen you are allowed to open, so a handful of controls are visible to you and refused by the server when pressed. Expect an error, not an effect.

On Users: Test User, Clean Tests, Import, creating a user, deleting a user, bulk-deleting users, blocking and unblocking an account, deleting a device, exporting another user’s data, granting or revoking superuser, granting or editing an entitlement override, and assigning, removing or re-dating a plan.

On Organizations: Provision Business Org, deprovisioning, and deleting an organisation.

On Notifications → Send Bulk: the whole screen. It enumerates and decrypts every user’s details across a whole deployment, so it stays central-only even though the sidebar lists it.

On Identity & Access → External Members: the whole screen, for the same reason — it reads through a central-only area.

On the Dashboard: every card except Recent Activity. See Notifications and logs.

The Two Extra Permissions

Alongside the role there are two permissions, granted one at a time, on top of it. They exist so you can hand somebody an emergency control without also handing them your members’ personal data.

can_revoke lets its holder cut off a peer server, in both directions. Your first admin is given this at install, because an emergency control that needs a command line in the middle of an incident is not an emergency control.

can_reveal lets its holder unmask one logged invitation address at a time, and lets them switch on the retention that makes a recoverable copy exist at all. It is off until you grant it, because it creates new personal data.

Grant them like this:

tc-operator add-admin --email someone@example.com --can-revoke
tc-operator add-admin --email someone@example.com --can-reveal

Take one back with --revoke plus that permission’s flag. --revoke on its own removes the role and both permissions.

Granting can_reveal prints a warning telling you the person can now unmask invited addresses. Every reveal is recorded permanently with the reader’s name, the time, and a reason they have to type.

Where you lack one of these permissions, the control is not offered. The Cut off button on a server row reads needs permission instead, and the show button beside a masked address is simply absent.