Provision jason and correct the OpenWebUI first-login role law
Provisioned the human account Frank asked for (Authentik username jason, jason@franksdank.cloud, template groups). The credential itself never enters
the repo — it travelled in stdin only and is not written to any file, page, or
commit here.
Live verification (why the docs changed)
ak shell create → pk 24, authenticate() truthy for the password and None for a wrong one, groups Non-Admin Users + jellyfin_users + openwebui_users (the 11-precedent human template), app_entitlements for
the open-webui application identical to the precedent user.
The Open WebUI roles mapping is a ScopeMapping attached to the Open WebUI OAuth2 provider's property_mappings, and the login request
asks scope=openid email profile roles — so the mapping rides the token.
Drove the real first SSO login in a clean managed browser: ai.franksdank.cloud → "Continue with authentik" (the login view shows no
password form — the SSO-only posture holds) → identification → password →
landed signed in as Jason.
The minted row is role='user' with zero manual steps. One chat turn
answered; "Read Aloud" issued exactly one POST /api/v1/audio/speech → 200
with no/wasm/ort-wasm-* fetch, and frank-tts logged speech voice=wilwheaton. A virgin account therefore lands on the server TTS
path by default.
Docs
Dankclaw/OpenWebUI.md — the First login mints role pending bullet is
destroyed and replaced: with ENABLE_OAUTH_ROLE_MANAGEMENT=true and the roles claim present, the claim decides the role; ui.default_user_role=pending is only the fallback for an account the claim
does not describe, and 0.12.5's get_user_role refuses the login with 403
when role management is on and no roles claim is readable. So "SSO worked but
I cannot chat" means a missing openwebui_users group/entitlement — not a row
waiting for the UPDATE "user" SET role='user' incantation, which stays
documented as the repair for a genuinely stuck row.
Infrastructure/Authentik.md — human-user template census gains jason,
pk 24 (created 2026-11-04); pk table re-read against authentik_core_user.
Not in this PR
scripts/, quadlets, Caddy: untouched. No deploy — documentation-only change
per the planner. The harness skill for this procedure
(authentik-provision-fleet-user) was corrected out-of-band: it still told
agents to append a dated entry to serverAppConfigs-docs/log.md, which was
destroyed 2026-10-19.
# Provision `jason` and correct the OpenWebUI first-login role law
Provisioned the human account Frank asked for (Authentik username `jason`,
`jason@franksdank.cloud`, template groups). The credential itself never enters
the repo — it travelled in stdin only and is not written to any file, page, or
commit here.
## Live verification (why the docs changed)
1. `ak shell` create → pk 24, `authenticate()` truthy for the password and
`None` for a wrong one, groups `Non-Admin Users` + `jellyfin_users` +
`openwebui_users` (the 11-precedent human template), `app_entitlements` for
the `open-webui` application identical to the precedent user.
2. The `Open WebUI roles` mapping is a `ScopeMapping` attached to the
`Open WebUI` OAuth2 provider's `property_mappings`, and the login request
asks `scope=openid email profile roles` — so the mapping rides the token.
3. Drove the **real first SSO login** in a clean managed browser:
`ai.franksdank.cloud` → "Continue with authentik" (the login view shows no
password form — the SSO-only posture holds) → identification → password →
landed signed in as Jason.
4. The minted row is **`role='user'` with zero manual steps**. One chat turn
answered; "Read Aloud" issued exactly one `POST /api/v1/audio/speech` → 200
with **no** `/wasm/ort-wasm-*` fetch, and `frank-tts` logged
`speech voice=wilwheaton`. A virgin account therefore lands on the server TTS
path by default.
## Docs
- `Dankclaw/OpenWebUI.md` — the *First login mints role `pending`* bullet is
destroyed and replaced: with `ENABLE_OAUTH_ROLE_MANAGEMENT=true` and the
`roles` claim present, **the claim decides the role**;
`ui.default_user_role=pending` is only the fallback for an account the claim
does not describe, and 0.12.5's `get_user_role` refuses the login with **403**
when role management is on and no roles claim is readable. So "SSO worked but
I cannot chat" means a missing `openwebui_users` group/entitlement — not a row
waiting for the `UPDATE "user" SET role='user'` incantation, which stays
documented as the repair for a genuinely stuck row.
- `Infrastructure/Authentik.md` — human-user template census gains `jason`,
pk 24 (created 2026-11-04); pk table re-read against `authentik_core_user`.
## Not in this PR
`scripts/`, quadlets, Caddy: untouched. No deploy — documentation-only change
per the planner. The harness skill for this procedure
(`authentik-provision-fleet-user`) was corrected out-of-band: it still told
agents to append a dated entry to `serverAppConfigs-docs/log.md`, which was
destroyed 2026-10-19.
---
cwd: /home/blank/.omp/wt/wt-20261104-104444-6d1fc1f · session: 01a1a7eb-c584-72d3-9d7e-c02d981cd662
Provisioned jason (pk 24, human-user template) and drove his first SSO
login in a clean browser: the row appeared as role='user' with chat and
wilwheaton TTS working, no manual step. The pending-then-flip law is
therefore wrong for a claim-carrying account - ENABLE_OAUTH_ROLE_MANAGEMENT
+ the roles scope decide it, and 0.12.5 refuses a claim-less login with 403
instead of falling back to ui.default_user_role. Census gains jason.
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.
Provision
jasonand correct the OpenWebUI first-login role lawProvisioned the human account Frank asked for (Authentik username
jason,jason@franksdank.cloud, template groups). The credential itself never entersthe repo — it travelled in stdin only and is not written to any file, page, or
commit here.
Live verification (why the docs changed)
ak shellcreate → pk 24,authenticate()truthy for the password andNonefor a wrong one, groupsNon-Admin Users+jellyfin_users+openwebui_users(the 11-precedent human template),app_entitlementsforthe
open-webuiapplication identical to the precedent user.Open WebUI rolesmapping is aScopeMappingattached to theOpen WebUIOAuth2 provider'sproperty_mappings, and the login requestasks
scope=openid email profile roles— so the mapping rides the token.ai.franksdank.cloud→ "Continue with authentik" (the login view shows nopassword form — the SSO-only posture holds) → identification → password →
landed signed in as Jason.
role='user'with zero manual steps. One chat turnanswered; "Read Aloud" issued exactly one
POST /api/v1/audio/speech→ 200with no
/wasm/ort-wasm-*fetch, andfrank-ttsloggedspeech voice=wilwheaton. A virgin account therefore lands on the server TTSpath by default.
Docs
Dankclaw/OpenWebUI.md— the First login mints rolependingbullet isdestroyed and replaced: with
ENABLE_OAUTH_ROLE_MANAGEMENT=trueand therolesclaim present, the claim decides the role;ui.default_user_role=pendingis only the fallback for an account the claimdoes not describe, and 0.12.5's
get_user_rolerefuses the login with 403when role management is on and no roles claim is readable. So "SSO worked but
I cannot chat" means a missing
openwebui_usersgroup/entitlement — not a rowwaiting for the
UPDATE "user" SET role='user'incantation, which staysdocumented as the repair for a genuinely stuck row.
Infrastructure/Authentik.md— human-user template census gainsjason,pk 24 (created 2026-11-04); pk table re-read against
authentik_core_user.Not in this PR
scripts/, quadlets, Caddy: untouched. No deploy — documentation-only changeper the planner. The harness skill for this procedure
(
authentik-provision-fleet-user) was corrected out-of-band: it still toldagents to append a dated entry to
serverAppConfigs-docs/log.md, which wasdestroyed 2026-10-19.
cwd: /home/blank/.omp/wt/wt-20261104-104444-6d1fc1f · session: 01a1a7eb-c584-72d3-9d7e-c02d981cd662