Roles and permissions

A role is a set of permission keys. A user can hold several roles, and their permissions are the union of them. A user assigned to no role gets the default role.

The two built-in roles

Role	What it grants
Administrator	Full access, including permissions added in future versions
Operator	The default: view every page, export, and the routine operational updates

Both are read-only — they cannot be edited, re-permissioned or deleted. You can duplicate one and edit the copy.

The catalog, by category

The catalog is defined on the server. The screen renders it; it does not define it. Each category carries one access ladder — at most one — and independent actions beside it.

Category	Access ladder
Events and calendar	View
Server inventory	View · Edit comments
Systems register	View · Edit · Merge and split
CVE vulnerabilities	View · Manage
System links	View
Databases	View · Edit
Network equipment	View · Edit
Virtualization	View · Edit
Storage	View · Edit
Cloud	View · Edit
Container platforms	View · Edit
Backup & protection	View · Edit
BIA and suggestions	View · Edit
Dashboards and alerts	View · Edit
System memory	View · Manage
Activity planning	View · Manage
Settings and configuration	View
Permissions and audit	View · Manage

The systems register has three rungs rather than two, because merging two records is not editing: it changes the system identity every other module joins on — BIA, the suggestions, the collision engine, the database inventory and the scheduling wizard all resolve a system by that same key.

Access level versus action

An access level is a single selector: None · View · Edit. Choosing a rung grants everything below it, so "edit without view" is not a state you can select — not a state you are warned about.

An action is a separate switch: export, cancel an event, mark a host as handled, answer an ownership attestation. An action can demand a minimum level; switching it on raises the level by itself, with a flash, and while it is on the rungs below its requirement are blocked, naming what blocks them.

That is why the editor distinguishes what you selected from what came out of it. Rows included by implication are marked as such, rather than as if someone had chosen them.

Members

Every role has a members tab. People are added through a directory search or by pasting a list of ids separated by commas or newlines — the same paste idiom as the product's other list pickers. The outcome of an action across a group of people is shown row by row: who was added, who was not, and why.

The Users view looks from the other direction — everyone the system has seen sign in, with their roles, and all of one user's assignments edited at once.

The guardrails

Situation	What happens
Removing the permission that grants you role management	Refused — you cannot lock yourself out
An operation that would leave the system with no administrator	Refused
Editing or deleting a built-in role	Refused
Deleting a role that still has members	Refused until you choose where they go
Removing an administrator defined in Access management	Refused, pointing at the screen where it does change

The guardrails are enforced on the server. The screen only shows them in advance, so you do not discover them after the click.

Role names are not translated

Role names and descriptions are data you write, so they render as stored in the English interface too — like system names and host names. The two built-in roles ship with Hebrew names.

---

A permission key is also the scope of an access token, and every change to a role is recorded in the change log.