Files
portal/docs
Bendik Aagaard LynghaugandClaude Fable 5.1 fc998c8592
Test / test (pull_request) Successful in 56s
One record answers another, from a list
Three small things that together make a board work: a link on every
listed record to a page about it (ResourceSpec.link, {id} and {field}
in the address); a state mail whose `to` is a field of the record this
one belongs to ({notice.email}), with that record's fields in the
text, and a lint that the form carries the record field it reaches
through; and value: "{user.email}" filled from the session and hidden,
so someone the site knows is not asked who they are.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt
2026-09-30 06:47:36 +02:00
..

portal documentation

Portal turns a Git repo of YAML into a running site. Almost everything here is about that YAML: what a content repo may say, and what the engine does with it.

Getting started Bringing your people in: from an empty Kanidm to everyone at their own desk, from what the content says.
Architecture What the engine is made of and where each piece lives in the source.
Content reference Every key a content repo may write, and what it does.
State machines aggregates.yaml: stages, who moves a case, mail, deadlines, memberships.
Access How the Cedar policy is compiled from content, and who may ask it what.
Operations Releasing, deploying, adding a site, environment variables.
Filesystem routes Why the questions/ tree is the router.

Two repos in the same family carry their own docs:

  • uhhm/iris — the lint. Versioned as portal and released by portal's publish job; it is the thing a content repo's CI runs before anything reaches a site.
  • uhhm/gdo — the mailer. Delivers what content asked to be sent, and carries replies back.