Roles

The roles page at /permissions/roles lists the roles that exist and manages their creation and removal.

Reading the list

Each row shows:

• the role’s name;
• its kind (structural or data);
• its parent (the role it inherits through);
• whether it is built in;
• how many users hold it (visible only if the caller manages users);
• whether it is editable by the caller.

Creating a role

The create form has three fields:

• name — the new role’s name;
• parent — an existing role to inherit from;
• access — a starter access level: none, read, or full.

The starter level hands the role a set of wildcard grants:

• none — no grants;
• read — read on data:*, journal:*, and ecb:*;
• full — read/insert/update/delete on data:* and journal:*, plus read on ecb:* (ECB rates are written by the server, so they are readable and nothing more).

The wildcards are deliberate: they keep covering profiles and tables added later. Creating a role redirects to the grants page with the new role selected, so its initial grants can be reviewed immediately. The grants are separate calls — if a starter grant fails partway, the role still exists and the failure names what is missing.

Removing a role

A role can be removed only when it is:

• editable (the caller outranks it);
• not built in;
• not currently assigned to any user.

The page hides the delete button otherwise and states why — outranks you, built in, or still assigned.