Responsible people get accounts. At start, every responsible.contact address Kanidm does not hold gets an account and a mail: "Du står oppført som ansvarlig for å stille «…» hos {site}" / "You are listed as responsible for asking “…” at {site}", with the one-time link. RESPONSIBLE_GROUP puts them all in one group; someone who already had an account is added without a mail. Once per address and group (portal_seed KV).
The first person in.SEED_ADMIN_EMAIL (+ SEED_ADMIN_NAME, SEED_GROUP) is invited once into the most privileged group: the group whose desk may invite into the most groups, read from the content (the board, on the vel). Retries a minute apart for twenty while Kanidm starts.
Suggest a change. Signed in as the page's responsible contact (the session now keeps the email claim), a card at the foot of the page takes a suggestion. The server re-checks the address against the page, stores it in portal_edit_suggestions, publishes portal.edits.suggested, and mails mail.reply_to with the suggester as reply-to.
Fix. Invites of new people failed where Kanidm has only the onboarding account: PUT /_attr/mail after creating answers 403 for idm_people_on_boarding (create, not modify). Measured on a Kanidm 1.11.2: create-with-mail 200, set-mail-after 403, add to a group the account manages 200, to one it does not 404. The address now goes in with the create.
Tests: 106 pass (seed group choice and keys, responsible collection, the responsibility check), and cargo leptos build --release builds server and wasm. The Kanidm calls were run against a local Kanidm 1.11.2 with the service account's real token; portal itself could not be booted against it, since its HTTP client trusts only webpki roots and the test Kanidm's CA is not among them.
**Responsible people get accounts.** At start, every `responsible.contact` address Kanidm does not hold gets an account and a mail: "Du står oppført som ansvarlig for å stille «…» hos {site}" / "You are listed as responsible for asking “…” at {site}", with the one-time link. `RESPONSIBLE_GROUP` puts them all in one group; someone who already had an account is added without a mail. Once per address and group (`portal_seed` KV).
**The first person in.** `SEED_ADMIN_EMAIL` (+ `SEED_ADMIN_NAME`, `SEED_GROUP`) is invited once into the most privileged group: the group whose desk may invite into the most groups, read from the content (the board, on the vel). Retries a minute apart for twenty while Kanidm starts.
**Suggest a change.** Signed in as the page's responsible contact (the session now keeps the `email` claim), a card at the foot of the page takes a suggestion. The server re-checks the address against the page, stores it in `portal_edit_suggestions`, publishes `portal.edits.suggested`, and mails `mail.reply_to` with the suggester as reply-to.
**Fix.** Invites of new people failed where Kanidm has only the onboarding account: `PUT /_attr/mail` after creating answers 403 for `idm_people_on_boarding` (create, not modify). Measured on a Kanidm 1.11.2: create-with-mail 200, set-mail-after 403, add to a group the account manages 200, to one it does not 404. The address now goes in with the create.
Tests: 106 pass (seed group choice and keys, responsible collection, the responsibility check), and `cargo leptos build --release` builds server and wasm. The Kanidm calls were run against a local Kanidm 1.11.2 with the service account's real token; portal itself could not be booted against it, since its HTTP client trusts only webpki roots and the test Kanidm's CA is not among them.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt
Every person a page names as responsible gets a Kanidm account at start
if they have none, and a mail saying they are listed as responsible for
asking that question, with the link to sign in; RESPONSIBLE_GROUP puts
them in one group. SEED_ADMIN_EMAIL invites the first person into the
most privileged group - the one whose desk may invite into the most -
once. Signed in, a responsible person may suggest a change to their
own pages; checked on the server, kept, published, and mailed to the
site's inbox.
Fixes an invite of someone new on a Kanidm with only the onboarding
account: the person is created with their address in one call, since
idm_people_on_boarding may create but not modify (it answered 403).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt
From an empty Kanidm to everyone at their own desk: what in the content
decides who needs an account, the four things Kanidm needs for portal,
the first person, what happens at start, how everyone after comes in
from the desks, what the people who ask the questions can do, and what
each failure looks like.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt
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
bl
merged commit a4c39e5ebc into main2026-09-29 19:10:40 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Responsible people get accounts. At start, every
responsible.contactaddress Kanidm does not hold gets an account and a mail: "Du står oppført som ansvarlig for å stille «…» hos {site}" / "You are listed as responsible for asking “…” at {site}", with the one-time link.RESPONSIBLE_GROUPputs them all in one group; someone who already had an account is added without a mail. Once per address and group (portal_seedKV).The first person in.
SEED_ADMIN_EMAIL(+SEED_ADMIN_NAME,SEED_GROUP) is invited once into the most privileged group: the group whose desk may invite into the most groups, read from the content (the board, on the vel). Retries a minute apart for twenty while Kanidm starts.Suggest a change. Signed in as the page's responsible contact (the session now keeps the
emailclaim), a card at the foot of the page takes a suggestion. The server re-checks the address against the page, stores it inportal_edit_suggestions, publishesportal.edits.suggested, and mailsmail.reply_towith the suggester as reply-to.Fix. Invites of new people failed where Kanidm has only the onboarding account:
PUT /_attr/mailafter creating answers 403 foridm_people_on_boarding(create, not modify). Measured on a Kanidm 1.11.2: create-with-mail 200, set-mail-after 403, add to a group the account manages 200, to one it does not 404. The address now goes in with the create.Tests: 106 pass (seed group choice and keys, responsible collection, the responsibility check), and
cargo leptos build --releasebuilds server and wasm. The Kanidm calls were run against a local Kanidm 1.11.2 with the service account's real token; portal itself could not be booted against it, since its HTTP client trusts only webpki roots and the test Kanidm's CA is not among them.🤖 Generated with Claude Code
https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt