serverAppConfigs-docs/Dankclaw/OpenWebUI.md

@@ -216,18 +216,26 @@ browser-driven and only touches the two exempt vhosts (`ai.` and `auth.`).
   into the existing local account with the same email — the pre-SSO admin
   (frank8465@protonmail.com) keeps its data. `ENABLE_OAUTH_SIGNUP=true` lets
   other `openwebui_users` create accounts on first login.
-- **First login mints role `pending`.** `ui.default_user_role=pending` (config
+- **First login mints the role from the claim, not from
-  DB, verified 2026-10-09), so a freshly-provisioned `openwebui_users` account
+  `ui.default_user_role`.** The quadlet sets `ENABLE_OAUTH_ROLE_MANAGEMENT=true`
-  completes SSO and then cannot chat (picker empty) until its role is flipped:
+  and `OAUTH_ROLES_CLAIM` defaults to `roles`, so the `roles: ["user"]` claim
-  `UPDATE "user" SET role='user' WHERE email='<user>@franksdank.cloud';` —
+  decides the role. Measured 2026-11-04: a freshly-provisioned
-  run with host `python3` over ssh against
+  `openwebui_users` account completed SSO in a clean browser and the row
+  appeared as `role='user'` — chat answered and Read Aloud synthesized, with no
+  manual step. `ui.default_user_role=pending` (config DB) is 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 succeeded but I cannot chat" points at a missing
+  `openwebui_users` group/entitlement, not at a row waiting to be flipped. Flip
+  only a row that is actually stuck:
+  `UPDATE "user" SET role='user' WHERE email='<user>@franksdank.cloud';` — run
+  with host `python3` over ssh against
   `/home/dank/Containers/open-webui/data/webui.db` (no `sqlite3` CLI on
-  Dankclaw; table is `user`, singular; no `active` column). No per-user model
+  Dankclaw; table is `user`, singular; no `active` column). The row does not
-  grant is needed: the picker model `frank-zealot` carries the global
+  exist until the account signs in, so census it after a first-login sighting
-  `access_grant` row `(model, frank-zealot, user, *, read)`, so any
+  (2026-10-09: five provisioned accounts had no row). No per-user model grant is
-  `role='user'` account sees it. Flip on FIRST-LOGIN SIGHTING — the row does
+  needed: the picker models carry the global `access_grant` row
-  not exist until the account signs in (2026-10-09: five provisioned accounts
+  `(model, <id>, user, *, read)`, so any `role='user'` account sees them.
-  had no row).
 - **IdP reachability:** the container is on its own bridge (10.89.3.0/24) and
   cannot reach `authentik-server:9000` by name. It reaches the IdP over the
   public URL `https://auth.franksdank.cloud` — Caddy publishes `0.0.0.0:443`

serverAppConfigs-docs/Infrastructure/Authentik.md

@@ -392,9 +392,10 @@ downstream —
 - `Non-Admin Users` = the plain-user marker group (precedents: qa-e2e, and
   every human account).
 - **The human-user template** (ridley, kassie, alex, artem, kirby, ry, nic,
-  debo, freya, mitch, eric). The pks in this page are confirmed against
+  debo, freya, mitch, eric, jason). The pks were confirmed against
-  `authentik_core_user` on 2026-10-18: ridley 13, kassie 14, alex 15,
+  `authentik_core_user` on 2026-10-18 and the table re-read 2026-11-04: ridley
-  artem 16, kirby 17, ry 18, nic 19, debo 20, freya 21, mitch 22, eric 23 —
+  13, kassie 14, alex 15, artem 16, kirby 17, ry 18, nic 19, debo 20, freya 21,
+  mitch 22, eric 23, **jason 24 (created 2026-11-04)** —
   and every one carries the `<user>@franksdank.cloud` address the template
   prescribes. Creation dates (2026-10-07 → 2026-10-15) were not re-checked
   - (unverified 2026-10-18)*. Template: `username` +