Administrators & Roles

User vs Member. A User is a Console administrator — someone who signs in to this application. A Member is a managed person who consumes access and never signs in here. They are separate account types with separate permissions. This chapter is about Users; members are in 02 · Members.

What you can do here

• As a system administrator, I want to create Console administrator accounts, so that colleagues can help operate the platform.
• As a system administrator, I want to assign roles to an administrator, so that they get exactly the access their job needs.
• As a system administrator, I want to design roles from individual permissions, so that least privilege is expressible.
• As a security officer, I want it to be impossible to grant a permission I do not hold myself, so that no one can escalate through the Console.

Part 1 — Console administrators (Users)

1. The user list

1.1 Columns

1.2 Statuses

1.3 Filtering

1.4 Row shortcuts

Double-click a row to open its detail. Single-clicking a row body toggles selection once at least one checkbox is ticked.

2. Console administrators: actions

Actions available on a user, from the row or the detail toolbar:

Which buttons a given row shows:

Users have no force-delete path. If a delete is refused, that is final until you clear the cause.

3. Creating an administrator

Route: /user/create · Permission: user:C

A two-step wizard plus a result step.

3.1 Step 1 — Basic information

Values you do not choose, because the flow fixes them:

3.2 Step 2 — Assign roles

Tick the roles this administrator should hold. You may create the account with no roles at all.

Two permissions are needed to edit this field: user:U and role:U. Assigning a role both writes to the user and hands out that role’s permissions, so you must be entitled on both sides. Missing either one makes the whole role list read-only, with an explanation — you can still create the account, just without roles.

Selecting a role is validated against your own permissions:

Judging this needs permission:R (to read the permission catalogue). Without it, or if the check fails for any reason, Merak fails closed: the role is blocked rather than allowed through unverified.

3.3 Step 3 — Result

The account is created first, then each selected role is assigned. If some role assignments fail the result page reports the partial failure explicitly rather than claiming success.

4. Copying an administrator

Entries: list row → /user/create/:id · detail toolbar → /user/:id/create · Permission: user:C

4.1 Copying never grants you more than you have

Copying is a creation, not a transfer of authority. Any account may be copied — including a Super Admin, and including yourself; the source is not restricted. But the copy must never give the operator more than they already hold.

The filter: a source role is seeded only if every single permission it contains is one you hold yourself. One missing permission removes the entire role from the seed, because a role is granted whole — there is no “grant part of a role”.

Dropping a role is never silent — a warning notification tells you how many roles were not copied because you cannot grant them. You may still tick roles manually in step 2, where the same validation and the same server-side check apply, so the outcome is identical.

5. Administrator detail

Route: /user/:id · Permission: user:R

Shows name, email, status, MFA required and MFA enabled, whether the account is a system account, created/updated times and editors, and the assigned roles.

Only the display name is editable inline; the roles are managed through the role picker.

Part 2 — Roles

6. What a role is

A role is a named bundle of permissions. Roles are tenant-scoped: the roles you see belong to your tenant.

The backend ships several system roles — Admin, ReadOnly, Member Editor, User Editor, Application Editor, and others. They carry a System badge in the list.

7. The role list

Filter: a single keyword field, fuzzy-matching name and description. Paging: default 10 per page.

Double-click a row to open its detail; single-click toggles selection once you are in selection mode.

8. Creating and editing a role

Route: /role/create · Permission: role:C

A dialog with two fields:

Editing happens inline on the role detail page and requires role:U.

Copying a role (/role/create/:roleId from the list, /role/:roleId/create from the detail) seeds <source name> - Copy with collision numbering, and seeds the source’s permissions filtered to the ones you can grant — the same anti-escalation rule as §4.1.

9. Managing a role’s permissions

Route: /role/:roleId/permission

The permission sub-page lists what the role currently grants:

Above the table, a search box matches resource, action or name live, and a resource dropdown filters to one resource (its options are built from the rows actually present, with “All resources” first).

9.1 Adding permissions

1. Select the add button.
2. Tick permissions from the catalogue. Ones already assigned are excluded.
3. Select Add.

You can only tick permissions you hold yourself. This is the same anti-escalation rule as everywhere else: the Console must never be a route to granting yourself more than you have.

9.2 Removing permissions

Select Remove on a row and confirm. Removal is not restricted — reducing privilege is always a safe operation.

9.3 One operation at a time

While an add dialog is open, or while an add/remove call is in flight, the other controls are disabled and the affected row shows a spinner. This prevents two conflicting writes to the same role.

10. The permission catalogue

Permissions are resource:action. There are 12 resources × 4 actions = 42 permissions in the catalogue, and the set is fixed — Merak does not invent new ones at runtime.

Not every combination is issued by the backend — auditLog:C, for example, never exists, because the audit log is not something you create. A permission that is never granted simply resolves to “not allowed”.

The full page-by-page matrix is in Appendix A.

11. Anti-escalation, in one place

Four separate defences enforce the same rule — you can never grant what you do not hold:

All four fail closed: if the check cannot be completed — the permission catalogue is unreadable, a role’s permissions cannot be fetched — the role or permission is refused, not allowed through unverified. The backend enforces the same rule independently; these defences exist so that the request is never sent in the first place.

12. Bulk work

Both users and roles support Export, multi-select batch actions and CSV import.

• Users: batch deactivate / activate / unlock / delete. The export carries a Roles column (gated on role:R). Import can create users and assign their roles; if any role assignment fails, that whole row counts as failed.
• Roles: batch delete only — roles have no lifecycle status. System roles are excluded from the eligible set up front rather than being allowed to fail one by one. The export carries a Permissions column (gated on permission:R). On import, a role whose body is created but one of whose permission grants fails still counts as succeeded — only a failure to create the role itself fails the row.

Full instructions: 09 · Bulk Operations.

13. Permission summary

Next

• Verify the effect of a role change: 07 · Logs
• Full permission matrix: Appendix A