Test / test (pull_request) Successful in 56s
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
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: