Users, teams and access¶

The Users section of the sidebar has two screens: People and Teams.

Accounts¶

An account has a name, a login, an e-mail address and a password. Two switches decide what it may do:

Active: An inactive account may not sign in and may not write anything.
Administrator: An administrator may do everything on the instance.

A plain account may edit its own record only. It may not create or delete accounts, and it may not change any role switch on any record, including its own.

A plain account may create workspaces, nodes and credentials. Each of them belongs to the account that created it: the account is its owner.

Teams¶

A team names a set of people, a set of workspaces and a set of nodes. Each workspace of the team carries an access level:

Viewer: Read the runs, the analyses, the comments and the logs of the workspace.
Developer: Everything that a viewer may do, and start the work: run a template, start and stop an analysis, start and stop a device, write a comment, upload a build.
Maintainer: Everything that a developer may do, and reshape the workspace. Only the owner deletes a workspace.

A workspace that a team assigns starts at the developer level.

The members of a team see the nodes of the team, and the nodes that the workspaces of the team run on.

Only an administrator may edit a team. A team is the record of who may work on what, so a member that could edit it could grant themselves a workspace.

How access is decided¶

The rule is the same for a read and for a write:

An account that is not signed in, or that is inactive, may do nothing.
An administrator may do everything.
A workspace, and the runs, analyses, test suites and attack vectors in it, belong to the owner of the workspace. Other accounts do not see them.
A team gives its members a seat on its workspaces, at the stated level. A record that names more than one workspace needs a seat on each of them.
A run or an analysis that names no workspace belongs to the administrators.

To found a new workspace takes no seat. To reshape a workspace takes its owner or a maintainer seat. To delete it takes its owner.

A node belongs to its owner. The owner and the administrators change and delete it. A workspace may run only on a node that its writer may see.

A credential belongs to the account that stored it. Only that account and the administrators see it, change it or delete it, and only they may point a node, a workspace or a test suite at it. Every account may store credentials. When a record uses a credential that the reader cannot see, the form shows “Set — a credential you cannot see”. The credential stays on the record when the reader saves it.

Workspaces, nodes and credentials from before Midair recorded owners have no owner. They belong to the administrators, and a team gives access to them.

The settings, the distribution registries and the code generation tooling belong to the instance and need an administrator.

Shared instance¶

An instance that several customers share declares the shared_instance feature. On such an instance:

An account sees no other account. The Users section is for administrators only.
Teams give nothing. Each account sees its own workspaces, nodes and credentials, and nothing else.
In a comment thread, a comment by an administrator shows as “Administrator”. A comment by another account shows as “Another account”.
Only administrators may open Bublik, and Midair gives Bublik accounts only to administrators. Bublik shows every project to each of its users. Other accounts read their logs in Midair.

Features¶

Three switches decide whether more than one of a thing may exist:

Feature	Collection	Without it
`multi_user`	`user`	one account
`multi_team`	`team`	one team
`multi_node`	`node`	one node

The switches gate the creation of the second record only. Reading, editing and deleting stay as they are, and an instance that loses a feature keeps the records that it already has.

The switches live in a features.js document in the data directory. The core reads it once at start and never writes it. No endpoint, no session, no token and no plugin can widen it from inside the running server. Whoever installs the instance installs that file.

A feature that the document does not declare is not permitted. An absent document and a malformed document both declare nothing.