Collection access rules

Define list, view, create, update and delete independently. Rules execute on the server for application users and service identities.

Owner-only issues

{
  "list": "actor.id != ''",
  "view": "owner_id = actor.id",
  "create": "actor.id != ''",
  "update": "owner_id = actor.id",
  "delete": "owner_id = actor.id"
}

Set these values in Settings → Collection access rules, save, then use the simulator with representative actors and record values. List rules authorize the operation; returned rows are still constrained by the rule’s record-aware predicate where applicable.

Public catalogue

{"list":"true","view":"true","create":"false","update":"false","delete":"false"}

Service-managed records

{"list":"actor.kind = 'service'","view":"actor.kind = 'service'",
 "create":"actor.kind = 'service'","update":"actor.kind = 'service'","delete":"false"}

A service must also possess the matching bearer scope. Rules can narrow a scope but cannot manufacture one.

Failure behavior

Individual view/update/delete denials avoid revealing whether a record exists. UI state is never an authorization boundary, and simulator output is diagnostic rather than a substitute for a real request test.

Provider storage

Rules are stored in collection metadata and evaluated server-side before any provider detail is exposed; the same authorization decision results on SQLite and the PostgreSQL provider. A denied record is indistinguishable from a missing record, and rule simulation is administrator-only.