Content model

Access and workflow

Declarative access rules per operation, and the draft, review, and publish lifecycle.


Each definition lists who may perform each operation: list, read, create, update, delete, publish, and public (whether published content is readable through /_public). A rule is a list of public, authenticated, owner (the document's creator, applied as a SQL condition on lists), or role names.

  • The admin role is always allowed, so a mistaken definition cannot lock everyone out.

  • New collections default to: list and read for authenticated users, create and update for editors, delete and publish for admins only, public reads for everyone.

  • The request user comes from the host: whatever the middleware set with c.set("user", { id, role }), from a session or an API key.

Draft and live copies

A document in a collection with drafts: true has a working copy (draft) and a live copy (data). The admin side reads the working copy; the public side reads only the live one.

  • Saving updates the working copy and sets status back to draft. A published document keeps its live copy and reports hasUnpublishedChanges.

  • Publishing copies the working copy to live, checks required fields, and records publishedAt.

  • Unpublishing moves the live copy back into the working copy and clears publishedAt.

  • Without drafts, writes go straight to the live copy and status is always published.

Review

Someone who may update but not publish moves the working copy between draft and in_review with POST /:collection/:id/_request-review and _withdraw-review. An admin then publishes with _publish. This is the path for AI agents on editor keys.

draft --request-review--> in_review --publish--> published
  ^                           |
  +------withdraw-review------+          unpublish -> draft

Every change writes a revision. GET /:collection/:id/_revisions lists them and POST /:collection/:id/_revisions/:revisionId/_restore restores one into the working copy.