Table Permissions

Sovrium controls record access with role-based access control (RBAC) at the table level, field-level permissions for granular column control, and optional row-level predicates for per-row scoping. Unauthorized access returns 404 (never 403) to prevent record enumeration.

Permission Values

Every operation accepts one of three formats:

The three built-in roles are admin, member, and viewer (highest to lowest). Custom role names are also accepted in the array form.

Table-Level Permissions

Set permissions on a table to gate each operation.

permissions:
  read: all
  comment: authenticated
  create: [admin, editor]
  update: [admin, editor]
  delete: [admin]

Restore and permanent delete

There is no separate restore or permanentDelete operation.

Restore shares the delete grant. Restoring is the inverse of soft-deleting, so both directions pass through one door: whoever may soft-delete a record may restore it. A separate grant would let the two sides drift apart, leaving one of them a weaker door onto the same operation.

Permanent delete is admin-only and not configurable. ?permanent=true erases the row irreversibly, so it is reserved for the admin role on every table regardless of permissions. Non-admin attempts return 404 (anti-enumeration), the same as any other unauthorized access.

Field-Level Permissions

Restrict read/write access to specific columns under permissions.fields. Each entry names a field and optionally its read and write audiences (same three formats). When a field permission is omitted, it inherits from the table-level read (for read) or create/update (for write).

A field a role cannot read is also not queryable by that role: filter, groupBy and aggregate on it return 404 (anti-enumeration), because a hidden column would otherwise leak its values through the result set — groupBy returns its distinct values, and aggregate its minimum and maximum. A field the role can read stays fully queryable.

permissions:
  read: authenticated
  fields:
    - { field: salary, read: [admin, hr], write: [admin] }
    - { field: department, read: all, write: [admin] }

Row-Level Permissions

Set rowLevelPermissions for defense-in-depth scoping. Each CRUD operation can carry a server-side when predicate that is appended as a filter to every record-returning request. The role gate runs first; the row-level predicate then filters within the permitted role's scope.

A predicate is { field, operator, value }:

rowLevelPermissions:
  read:
    when:
      field: client_id
      operator: in
      value: { kind: currentUser, path: { kind: assignment, tableSlug: clients } }
  write:
    when:
      field: client_id
      operator: in
      value: { kind: currentUser, path: { kind: assignment, tableSlug: clients } }

Resource:Action Permissions

For broader permission contexts (admin plugin, API keys), Sovrium also supports a resource: [actions] map where each resource lists allowed actions and * means all actions:

users: [read, list]
posts: [create, read, update, delete]
analytics: ['*']