Permissions

A permission is a named atomic action a user can be allowed to perform — read a page, create a page, upload an attachment, and so on. Permissions are the building blocks of Roles: every role is a bundle of permissions, and a user's effective rights are the union of all permissions across every role they hold.

GeoHazardWatch uses simple string keys for permissions (e.g. page-edit, asset-upload). They are deliberately flat — no Context/Resource/Action triple, no scoping by namespace. The per-page rules (Page Private, Author Lock, Page Audience) operate at a layer above permissions; they override what a role-granted permission would otherwise allow.

Live Permissions Catalog

The table below is rendered from the live configuration at view time. It groups permissions by the resource they act on (page-*, asset-*, search-*, user-*, admin-*).

Roles × Permissions Matrix

Which roles grant which permissions, rendered live:

Reading the Tables

• Permission — the lowercase string key used in Roles definitions and in access-policy actions lists
• Description — short summary of what the permission allows
• Group prefix (page, asset, search, user, admin) — the resource the permission operates on

How Permissions Are Checked

When a user attempts an action on a page, the access-control flow is:

1. Tier 0 — Private pages restrict to admins and the page creator regardless of permissions. See Page Private.
2. Tier 1 — Per-page overrides (audience or access) take precedence over role permissions for that page. See Page Audience.
3. Tier 2 — Global access policies grant or deny based on the user's roles and their associated permissions.

A user must hold at least one role whose permission set grants the requested action — unless a per-page override allows them explicitly.

See Also

• Roles — the catalog of role bundles that grant these permissions
• Page Private — strongest per-page override (Tier 0)
• Page Audience — per-page view-access override (Tier 1)
• Author Lock — per-page edit restriction