ae6473635d
Follow-up to the UiAuthController fix: every write path that puts a row
into users/user_roles/user_groups must use the bare DB key, because
the env-scoped controllers (Alert, AlertRule, AlertSilence, Outbound)
strip "user:" before using the name as an FK. If the write path stores
prefixed, first-time alerting/outbound writes fail with
alert_rules_created_by_fkey violation.
UiAuthController shipped the model in the prior commit (bare userId
for all DB/RBAC calls, "user:"-namespaced subject for JWT signing).
Bringing the other two write paths in line:
- OidcAuthController.callback:
userId = "oidc:" + oidcUser.subject() // DB key, no "user:"
subject = "user:" + userId // JWT subject (namespaced)
All userRepository / rbacService / applyClaimMappings calls use
userId. Tokens still carry the namespaced subject so
JwtAuthenticationFilter can distinguish user vs agent tokens.
- UserAdminController.createUser: userId = request.username() (bare).
resetPassword: dropped the "user:"-strip fallback that was only
needed because create used to prefix — now dead.
No migration. Greenfield alpha product — any pre-existing prefixed
rows in a dev DB will become orphans on next login (login upserts
the unprefixed row, old prefixed row is harmless but unused).
Operators doing a clean re-index can wipe the DB.
Read-path controllers still strip — harmless for bare DB rows, and
OIDC humans (JWT sub "user:oidc:<s>") still resolve correctly to
the new DB key "oidc:<s>" after stripping.
Verified: 45/45 alerting + outbound ITs pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>