docs(e2e): how to set the E2E account admin role (SQL + bootstrap) #141

Merged

nrupard merged 1 commit from docs/pms-155-e2e-admin-howto into main

2026-06-09 17:49:41 +02:00

nrupard commented

2026-06-09 17:19:55 +02:00

Owner

What

Follow-up to #140. Expands the E2E account provisioning step with the exact mechanism for setting the account's admin role.

The E2E account reaches mokosh on the bunyip Resource-Server path (ensure_user_from_bunyip), which resolves the request role from the mokosh users table row, not from the access token. The row is auto-created on first login with the default role = 'technician', which is why the module specs 403. The README now documents:

the direct-DB UPDATE users SET role = 'admin' to flip it (takes effect on the next request, no re-login),
the admin-API alternative (PUT /api/v1/users/{id} with {"role":"admin"}), and
the OAUTH_SUPER_ADMIN_EMAILS Google-path bootstrap for the first admin (noting it does not apply to the bunyip SSO path the E2E account uses).

Docs only.

🤖 Generated with Claude Code

## What Follow-up to #140. Expands the E2E account provisioning step with the exact mechanism for setting the account's admin role. The E2E account reaches mokosh on the bunyip Resource-Server path (`ensure_user_from_bunyip`), which resolves the request role from the mokosh `users` table row, not from the access token. The row is auto-created on first login with the default `role = 'technician'`, which is why the module specs 403. The README now documents: - the direct-DB `UPDATE users SET role = 'admin'` to flip it (takes effect on the next request, no re-login), - the admin-API alternative (`PUT /api/v1/users/{id}` with `{"role":"admin"}`), and - the `OAUTH_SUPER_ADMIN_EMAILS` Google-path bootstrap for the first admin (noting it does not apply to the bunyip SSO path the E2E account uses). Docs only. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nrupard added 1 commit

2026-06-09 17:19:55 +02:00

docs(e2e): spell out how to set the E2E account's admin role (SQL + bootstrap)

E2E (staging) / Playwright against staging (pull_request) Failing after 56s

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 1m42s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

67c9cb820b

Expand the provisioning step with the exact mechanism. The E2E account reaches mokosh on the bunyip Resource-Server path (ensure_user_from_bunyip), which resolves the request role from the mokosh `users` table row, not from the access token; the row is auto-created with the default `role = 'technician'`. Document the direct-DB UPDATE to flip it to `admin`, the admin-API alternative (PUT /api/v1/users/{id}), and the OAUTH_SUPER_ADMIN_EMAILS Google-path bootstrap for the first admin (noting it does not apply to the bunyip SSO path the E2E account uses).

#PMS-155

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>