HOC SiteDocumentation

Permissions

Three independent layers — public access on the object type, platform roles for people who work in the panel, and website user roles for people who sign in to the site.

Public access

Public permissions are stored on the object type and decide what an anonymous visitor can do:

  • create — a visitor may create an entry. This is how registration and contact forms work.
  • view_all — a visitor may list entries. view_all can carry conditions, and an unconditioned view_all makes every row public.
  • fields — per-field read and write grants, each with optional conditions.

Anonymous update and delete follow the same view_all conditions. A missing cookie-backed site variable in a condition fails closed.

Platform roles

Platform roles decide who can work on a website in the admin panel: who may create routes, edit pages and components, edit chrome, manage object types, define or invoke integrations, and manage secrets. A role also carries per-object-type slices for entries and fields, split into own and others.

Super admin and admin are special roles and cannot be edited through the API.

Website user roles

Website user roles decide what a signed-in visitor can do with object entries. Each object type slice has four booleans:

  • see_own, see_others, mutate_own, mutate_others.

Each grant can carry conditions, so "own" does not have to mean "same user": it can mean "same value in a relation field".

Conditions

Conditions are field_compare (left path, operator, right value) or entry_age (younger/older than a number of minutes, hours, or days). The right side can be a literal, the acting user's field, or a cookie-backed site variable.

scopeRelationFieldKey is a shortcut: on a true grant with no conditions it is stored as a field_compare of that key against the actor's same key.