Permission Reference

1. How a permission key is written

<resource>:<action>

The catalogue holds exactly 42 permissions across 12 resources, and the set is fixed — Merak does not mint new permissions at runtime. Ten resources carry the full C/R/U/D set; permission and auditLog are read-only and exist solely as permission:R and auditLog:R (10 × 4 + 2 = 42).

2. Page access matrix

Holding the listed permission is what makes the menu entry appear and the route open. Without it, the menu entry is hidden and typing the URL shows a “no access” result.

A menu group disappears when every one of its children is hidden.

3. Action matrix by resource

3.1 Members

Cross-feature: the Devices card needs device:R, Organizations organization:R, Applications application:R, the Log tab auditLog:R. Losing one hides that card or tab entirely.

3.2 Devices

3.3 Applications

3.4 Organizations

3.5 Merak Nodes

⚠️ Merak Nodes are the one exception to “missing permission = missing button”. The Console gates the page on merakNode:R, but the create, rename, regenerate and delete controls are shown to anyone who can open the page — they are filtered by deployment status only. The merakNode:C/U/D keys exist and the backend applies them, so an action you are not entitled to fails at submit rather than being hidden. Treat a visible button here as “you may try”, not “you may do”.

3.6 Approvals

3.7 Logs

3.8 Users (Console administrators)

3.9 Roles

3.10 Profile and Preferences

4. Rules that apply everywhere

4.1 Missing permission = missing button

A control you have no permission for is not rendered, not disabled. If a button you expect is absent, check the permission before you file a bug.

One exception: Merak Nodes. Its create, rename, regenerate and delete controls are not permission-filtered in the Console — only the page is. See §3.5.

4.2 Cross-feature dependencies hide whole sections

When a page needs another resource’s data, losing that resource’s read permission removes the whole card, tab or filter field — Merak does not show an empty card you could mistake for “there is nothing here”. It also stops asking the server for data you may not read.

4.3 Both sides are needed to grant access

Granting access writes to two records, so it needs permission on both:

A field you cannot fully edit becomes read-only and submits as empty — it never smuggles a pre-ticked seed value past your permissions.

Read-only pickers used purely to find a source (the organization option in the quick-select pickers) need only that resource’s read permission, because nothing is written to it.

4.4 You can never grant what you do not hold

Enforced in four places — copying a user, copying a role, assigning a role manually, and importing roles. All of them fail closed: if the check cannot be completed, the grant is refused rather than allowed through unverified. See 08 · Administrators & Roles §11.

4.5 Every default role carries tenant:R and license:R

That is why tenant name and quota normally work. An account with no roles at all may still be refused, and every screen that reads them degrades gracefully rather than failing.

5. System accounts and system roles

Batch delete on roles excludes system roles from the eligible set up front, rather than letting each one fail against the server.