Users and Permissions

Two things decide what somebody sees in Selvara. The role says what a person may do — read, acknowledge, manage, administer. The grant says which customers that applies to. Neither answers the other's question: a manager with no grant may create systems in principle and has nowhere to put them, and a viewer granted three customers still cannot touch anything in them.

Administrators are the exception to the second half. An administrator reaches every customer there is, without being granted one, and nothing narrows that.

Everyone else starts with nothing. A freshly created manager, operator or viewer sees an empty instance until an administrator gives them a customer.

The four roles

Role	What it may do
Administrator	Everything, everywhere. Accounts, roles, grants, SMTP and the agent rollout mode are administrator work only.
Manager	Runs the customers granted to it: creates and deletes customers and systems, renames clusters, writes alert rules, event rules and maintenance windows, changes agent settings, acknowledges and deletes alerts. Not the instance itself — no accounts, grants or SMTP.
Operator	Reads the customers granted to it and acknowledges or resolves their alerts. Creates, changes and deletes nothing.
Viewer	Reads the customers granted to it. No buttons — and the API refuses the request as well, not only the interface. Never notified.

In detail:

Action	Administrator	Manager	Operator	Viewer
See systems, alerts, metrics, timeline	every customer	granted customers	granted customers	granted customers
Acknowledge or resolve an alert	yes	granted customers	granted customers	no
Delete an alert	yes	granted customers	no	no
Create, end or delete a maintenance window	yes, any scope	scopes it reaches in full	no	no
Create, edit, enable, disable or delete an event rule	yes, any scope	scopes it reaches in full	no	no
Create, edit, enable, disable or delete an alert rule	yes, any scope	scopes it reaches in full	no	no
Create a customer	yes	yes, and is granted it	no	no
Edit or delete a customer	yes	granted customers	no	no
Add, edit or delete a system, regenerate its key	yes	granted customers	no	no
Rename or delete a cluster	yes	clusters it reaches in full	no	no
Change agent settings for a system or a cluster, switch services off on the Services tab	yes	systems and clusters it reaches in full	no	no
Hold or release agent updates	yes	granted customers	no	no
Set the agent rollout mode	yes	no	no	no
Move the agents to a new server (Agents → Server move)	yes	no	no	no
Create accounts, change roles, set grants	yes	no	no	no
Configure SMTP	yes	no	no	no
Set how long resolved alerts are kept	yes	no	no	no
Receive notifications	always	granted customers	granted customers	never

A manager who creates a customer is granted it in the same step, so it does not vanish from their list the moment it exists. Moving a system to another customer needs both ends: the customer it leaves and the one it joins.

The navigation reflects this. The settings section offers Users and Notifications to administrators, Alert rules, Maintenance windows and Event rules to administrators and managers, and the agent download to everyone. What the sidebar shows is presentation only: it hides a link, it does not guard anything. The check that matters is the one in the API, and it runs whether the link was there or not.

Accounts

Accounts live under Settings → Users, which is administrator-only.

Add user asks for an email address, an optional name, a password and a role. The role select offers the least privileged first and starts on Viewer. The dialog says plainly that the new account sees nothing yet — customers are granted after it exists, not while it is being created.

Editing an account changes its email, name, password, avatar image (up to 2 MB) and role, and is where the customer list for that account lives. An empty password field leaves the stored password alone.

Anyone may edit their own name, email, password and avatar from their profile, whatever their role. Only an administrator can change a role, and nobody can delete their own account.

Passwords

One rule applies wherever a password is set — the first account on /setup, a Forgot password link, the profile, an administrator editing a user, and scripts/reset-password.mjs:

• at least 8 characters, at most 200;
• and not easy to guess. Each password is scored with zxcvbn, which knows the common passwords, English and German words and names, keyboard rows, repeats, dates and years, and the account's own email address, name and username. A password must reach 2 on its scale of 0 to 4, which eight random characters do and Sommer2024, Passwort123 or qwertzuiop do not.

The field shows the strength while you type and, below the bar, why a weak password is weak. The same check runs again on the server, so the API refuses what the form would. Several unrelated words — kupfer lampe wolke sieben — are the easiest way to a strong password.

Existing passwords are not checked again; the rule applies the next time one is set.

Trusted devices

At sign-in, Trust this device for 30 days lets a browser skip the second factor — the password is still asked for every time. The trust is fixed at 30 days from the sign-in that granted it and does not extend with use; signing in with the code again replaces the browser's entry rather than adding one. Each account lists its trusted browsers under Profile → Security, where they can be revoked singly or all at once. All of them are revoked whenever the password changes — by Forgot password, from the profile, by an administrator or with scripts/reset-password.mjs — and when the authenticator app is removed. The cookie is marked Secure, so over plain http:// the browser drops it and the code is asked for every time.

Grants

A grant is one row saying this account may reach this customer. There is no level on it: the role already decided what the person may do, and the grant only decides where.

An administrator is never listed. Their reach is implicit, and a row for one would suggest it could be taken away a customer at a time. Both directions of the interface refuse to store one, and the edit dialog replaces the customer list with a line saying so as soon as the role is set to Administrator.

From the customer

The customer's own page has a Users tab, visible to administrators. It lists every account below administrator with a checkbox, ticked where the grant already exists. Tick, untick, Save changes.

From the account

The edit dialog under Settings → Users has a Customers list, with the same checkboxes seen from the other end, and a count of how many are ticked.

Both replace the whole set

Whichever end you work from, saving sends the complete list and replaces what was stored. There is no add and no remove. Untick a box and save, and that grant is gone; the save cannot half-apply, because the replacement happens in one transaction.

Deleting an account or deleting a customer takes its grants with it.

An account with no grant

A person below administrator who has been granted nothing gets an explanatory screen, not an empty one. The overview, the systems list and the alerts page all say No customer yet with a note that an administrator can change that under Settings → Users.

This matters more than it sounds. "No active alerts" and "no systems" are correct answers for an account that may see nothing, and they read exactly like an estate that has gone away — a fresh operator would reasonably report an outage. The two states have to say different things, so they do.

Such an account is also not notified about anything, whatever it has ticked in its profile. Creating the account and leaving the grant for later means that person is silently off the on-call list until somebody remembers.

What a grant opens up

Once an account holds a customer, everything scoped to that customer follows: its systems and their detail pages, its metrics and charts, its alerts and alert counts, and the events of its systems on the timeline. The suggestion and filter values follow: the region and tag dropdowns on the systems page are built from the systems that account can see, so a filter cannot be used to enumerate another customer's region names.

The customers page lists the granted customers and no others. The overview's counters and attention tiles are counted over the same set.

Notifications

Who is told about an alert or a notifying event:

Role	Notified
Administrator	Always, about everything.
Manager, Operator	When the account is granted one of the customers the alert or the event touches.
Viewer	Never.

An alert touches exactly one customer: the one its system belongs to. An event usually does too, but a cluster event touches every customer its members belong to — a failover in a cluster with nodes at two customers notifies the managers and operators of both. Somebody holding two of the customers a single event touches is still mailed once.

An event that belongs to no system and no cluster reaches administrators only, because there is no customer on it for a grant to match.

Whether the mail actually goes out is a separate question, answered by the instance's SMTP settings and the person's own preference; see Notifications. The grant decides whether somebody is a recipient, the preference decides whether they hear about it.

Clusters

A cluster is not owned by a customer. Its members are, and they need not all belong to the same one — an HAProxy in front of two customers' machines is the ordinary case. So the reach into a cluster is asked of its members, and it is deliberately lopsided:

• Seeing any one member is enough to read the cluster. Otherwise a cluster with a single node at another customer would hide a node of your own, along with its failovers. You then see only the members you may see: the member list, the per-node values and the settings form are all built from those.
• Writing takes every member. A cluster-wide maintenance window silences the alerts of machines at every member's customer, and a cluster-scoped event rule forwards their events. A read shows a hostname; a write reaches into somebody else's estate. The same bar applies to a cluster's agent settings, to renaming it and to deleting it: what is saved lands on every member machine and may carry a token.

A cluster with no member you can see is out of reach entirely. One with no members at all is out of reach for everybody but an administrator, who has to be able to find the leftovers of a cluster whose machines are gone in order to clear them away.

Maintenance windows, event rules and alert rules

A maintenance window and an event rule each have at most one scope, and that scope reaches further than it names — a customer-scoped window silences every system of that customer, a cluster-scoped rule notifies about every member. So the bar for writing one is that you could have written that scope yourself:

Scope	Who may write it
One system	Administrators and managers granted its customer.
One customer	Administrators and managers granted that customer.
One cluster	Administrators and managers granted every member's customer.
Everything	Administrators only.

The last row is the one to remember. A window over all systems and an event rule with no scope stop or forward alerts for every customer in the instance, which is more than any grant can add up to, so they stay with administrators however many customers a manager holds. The same goes for moving an existing rule onto a scope: the place it is being moved to has to be writable too, or a rule you may edit becomes a way to write one you may not.

Reading is narrower than the instance and wider than writing. The window and rule lists show what the account reaches, and nothing else — a window naming another customer's system, and the name and address of whoever opened it, is not your business.

One exception: an instance-wide maintenance window stays visible to everybody, even though only an administrator can open one. It silences their systems too, and hiding it would leave them looking at hosts marked under maintenance with nothing on screen that says why.

Alert rules follow the same table, with one difference: an alert rule may name a customer and a cluster together and applies where they overlap, so every scope it names has to be writable. The alert rule list is filtered the same way. An unscoped rule — the shape every seeded rule has — counts as instance-wide, and so does one narrowed only by service, since a service turns up at whichever customers happen to run it. The form therefore does not offer a manager all customers: they pick a customer or a cluster.

Like the instance-wide maintenance window, an instance-wide alert rule is shown to managers, read-only: it raises alerts on their systems, and without it they could not tell where those alerts come from. Such a rule, and one on a cluster the manager reaches only in part, carries an eye instead of the edit buttons; it opens the rule's condition, duration and scope. Customer view leaves instance-wide rules out, as described below.

Customer view

Customer view narrows one browser to one customer, for opening the dashboard at the customer's site or on a shared screen. The eye button under your name at the bottom of the sidebar (Customer view) asks for the customer; from then on every page, list, count, chart and live update in that browser covers that customer only, as if the account had been granted nothing else. Another customer's system, alert or cluster reads as not found, even by its direct link.

While it is on, a light blue frame runs round the whole window, a banner above your name shows the customer, and the browser tab starts with its name. End customer view in that banner returns to everything the account can reach.

What the role allows stays as it is, inside the customer: a manager or an administrator can still acknowledge alerts, edit systems, renew agent keys and write that customer's alert rules, event rules and maintenance windows. What belongs to the whole instance is taken away for the duration, including for an administrator: accounts, the mail server, moving servers, the agent rollout, and rules and maintenance windows that cover every customer. Those are not shown at all, since their names are written for the operator and may mention other customers.

The view belongs to the browser, not to the account. It is kept in a cookie for thirty days, so a laptop left at a customer does not fall back to every customer when it is switched on again. The account's other sessions, the desktop app, API tokens and the notifications it receives are not affected. If the customer is deleted, or the account loses its grant for it, the view shows nothing until it is ended, rather than quietly showing everything.

Why a missing resource and a forbidden one give the same answer

Three status codes come back from the API:

Code	Means
401	Nobody is signed in.
403	Signed in, but the role is not enough for this action.
404	The resource is not there — or it belongs to a customer this account cannot reach.

The third is the deliberate one. Told apart, the pair turns an id into an oracle: a 403 on a system id would confirm that the system exists at a customer you were never given, and walking a list of ids would map an estate you may not see. One answer for both means an id tells you nothing you did not already know.

The same reasoning runs through the rest of the API. A maintenance window or an event rule outside your reach reads as not found; a scope you cannot write reads as unknown scope, exactly like one that was deleted; a cluster with no visible member reads as missing. Where the role is the problem rather than the customer — a manager trying to open an instance-wide window — the answer is a plain 403, because that fact is not a secret.

When a change takes effect

Every permission check — the dashboard shell and its navigation, the lists and detail pages, every API endpoint — reads the account's role and its grants from the database on each request, rather than trusting the sign-in token. So:

• A grant given or withdrawn applies to the next page load and the next request.
• A promotion or a demotion applies to all of that at once. The person does not have to sign in again for it to bite.
• A deleted account can no longer load the dashboard: the shell sends it to the sign-in page, and every customer-scoped request answers 401.

There is one bound worth knowing. The live event stream is a long-lived connection whose permissions are resolved when it connects, and the connection is capped at fifteen minutes before the browser reconnects and is checked afresh. A grant withdrawn while somebody has a dashboard open can therefore keep feeding live alert and status messages for that customer for up to fifteen minutes. Pages, lists and API requests are already refusing at that point; it is only the open stream that lags. Where that is not acceptable, delete the account or change its role — a stream whose session is gone fails its next reconnect.

The stream's metric channel is administrator-only. A metric message names no customer, so nothing on that channel can be told apart by customer, and it is refused rather than delivered unfiltered. Nothing in the interface asks for it.

The sidebar and the buttons on each page follow the role as the dashboard shell last read it, so a demotion shows from the next page load. Hiding a link or a button is presentation, never a control.

API tokens follow the same rule, and there is no exception to it for them. A token carries its owner's identity and nothing else, so a grant, a promotion, a demotion or a deletion reaches a program on its very next request. A token never has to be reissued after a permission change, and reissuing one would not widen what it may do.

Common setups

One customer per client, a manager and operators each. Create a customer per client, put its servers in it (see Customers and Systems), and grant it to that client's people. The manager adds and removes servers, writes the rules and opens maintenance windows; the operators on call acknowledge alerts and get the mail. Your own administrators keep the instance-wide view, the instance-wide rules and the accounts.

A read-only account for the client's own staff. A viewer granted that one customer sees its systems, charts, alerts and timeline and can change nothing. Because viewers are never notified, this is also the account to hand out when somebody wants to look but must not end up on the on-call list. Give them the same customer their operator has; both are narrowed by the grant, and the role is what separates looking from acting.

One team, everything. A small team that is on call for the whole estate is simplest as administrators, since an administrator needs no grants and no maintenance of them. Use managers the moment somebody should not be able to edit accounts or SMTP — a grant on every customer gives a manager the same estate without the instance's settings — and operators for people who should only acknowledge.

A manager across a shared cluster. If a cluster spans two customers and somebody has to be able to silence it with a single maintenance window, or write an event rule for it, they need both customers granted, not one. Granting one lets them read the cluster and see their own nodes in it, which is often all they need — while the cluster's agent settings stay with whoever holds every member's customer.

Related: Customers and Systems for what a customer groups, Notifications for the channels behind the recipient rules, and Maintenance Windows, Alert Rules and Event Rules for the scopes the grants are measured against.