Files
portal/docs
Bendik Aagaard LynghaugandClaude Fable 5.1 ef4789f9b2
Test / test (pull_request) Successful in 56s
Invites and suggestions are cases; the responsible follow the content
Five things the first cut of accounts-from-content left open.

The first person and the responsible people are set up side by side,
and both try again a minute apart: a seed that waited twenty minutes on
Kanidm used to hold everyone else up, and a responsible person who
failed waited for the next restart.

The responsible are gone over again whenever the content changes.
watch_for_reload publishes portal.content.reloaded once new content is
in place, and seed.rs listens.

Being responsible ends when the content stops saying so: someone no
page names any more leaves RESPONSIBLE_GROUP in the same pass, if
portal is who put them there (Invited.already_member). The account
stays.

An invite keeps itself current. portal_invites has an expired state;
signing in closes a person's invites, a sweep moves the ones whose link
ran out, and a desk's move from expired back to open makes a fresh link
and mails it. Invites made at start are on file with the desks'.

A suggested edit is a case in the built-in portal_edit_suggestions
bucket, the person who made it is mailed at each move, and the card
lists what they sent and where it stands.

Found on the way, against Kanidm 1.11.2: a link's end comes as seconds
since the epoch, which portal did not read, so invite mails said
"until" and nothing; and a mail search answered with a 5xx was taken
for a refusal.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt
2026-09-29 21:00:10 +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.