Separate ADMIN_EMAIL from site users #174

New issue

Closed

opened 2026-06-21 11:20:46 -05:00 by erik · 3 comments

erik commented

2026-06-21 11:20:46 -05:00

Owner

Summary

The Site users settings page shows the configured ADMIN_EMAIL as a normal editable site user. This is confusing because ADMIN_EMAIL is a deployment-configured bootstrap/recovery admin identity, not a regular user managed from the Site users table.

Steps to reproduce

Set ADMIN_EMAIL in the dev or deployment environment, for example slug@example.com.
Sign in as an admin.
Open Settings → Site users.
Compare the configured ADMIN_EMAIL row with normal stored users.

Expected behavior

The configured ADMIN_EMAIL is shown in its own recovery/bootstrap admin email section.
The section identifies it as deployment-configured and explains that changing it requires deployment configuration, not Site users edits.
If a matching stored site user exists, the section shows its current stored status/roles for context.
The normal Site users table does not present ADMIN_EMAIL as an ordinary editable user.
Admins cannot accidentally deactivate or demote the bootstrap/recovery identity from the normal Site users table.

Actual behavior

The configured ADMIN_EMAIL appears in the normal Site users table beside regular users.
It has normal role update and deactivate controls.
The UI does not explain that this email is special bootstrap/recovery configuration.

Acceptance criteria

Settings → Site users has a dedicated recovery/bootstrap admin email section showing the configured ADMIN_EMAIL.
The recovery/bootstrap section states that ADMIN_EMAIL is configured from deployment environment and must be changed in deployment config.
When the configured ADMIN_EMAIL has a stored site-user record, the section shows its stored status and roles for context.
The normal Site users table does not show the configured ADMIN_EMAIL as a normal editable row, or otherwise disables role/deactivate controls with clear explanatory copy.
Admins cannot deactivate or demote the configured bootstrap/recovery identity through the normal Site users table controls.
Tests cover the Site users page when ADMIN_EMAIL has a matching stored user.
Tests cover the Site users page when ADMIN_EMAIL does not yet have a stored user.

## Summary The Site users settings page shows the configured `ADMIN_EMAIL` as a normal editable site user. This is confusing because `ADMIN_EMAIL` is a deployment-configured bootstrap/recovery admin identity, not a regular user managed from the Site users table. ## Steps to reproduce 1. Set `ADMIN_EMAIL` in the dev or deployment environment, for example `slug@example.com`. 2. Sign in as an admin. 3. Open Settings → Site users. 4. Compare the configured `ADMIN_EMAIL` row with normal stored users. ## Expected behavior - The configured `ADMIN_EMAIL` is shown in its own recovery/bootstrap admin email section. - The section identifies it as deployment-configured and explains that changing it requires deployment configuration, not Site users edits. - If a matching stored site user exists, the section shows its current stored status/roles for context. - The normal Site users table does not present `ADMIN_EMAIL` as an ordinary editable user. - Admins cannot accidentally deactivate or demote the bootstrap/recovery identity from the normal Site users table. ## Actual behavior - The configured `ADMIN_EMAIL` appears in the normal Site users table beside regular users. - It has normal role update and deactivate controls. - The UI does not explain that this email is special bootstrap/recovery configuration. ## Acceptance criteria - [ ] Settings → Site users has a dedicated recovery/bootstrap admin email section showing the configured `ADMIN_EMAIL`. - [ ] The recovery/bootstrap section states that `ADMIN_EMAIL` is configured from deployment environment and must be changed in deployment config. - [ ] When the configured `ADMIN_EMAIL` has a stored site-user record, the section shows its stored status and roles for context. - [ ] The normal Site users table does not show the configured `ADMIN_EMAIL` as a normal editable row, or otherwise disables role/deactivate controls with clear explanatory copy. - [ ] Admins cannot deactivate or demote the configured bootstrap/recovery identity through the normal Site users table controls. - [ ] Tests cover the Site users page when `ADMIN_EMAIL` has a matching stored user. - [ ] Tests cover the Site users page when `ADMIN_EMAIL` does not yet have a stored user.

erik added the

status:inprogress

bug

priority:medium

labels

2026-06-21 11:20:46 -05:00

erik commented

2026-06-21 11:26:14 -05:00

Author

Owner

Synced from todu comment by @todu on 2026-06-21T16:22:14.829Z

Review update

PR: #175 is open and reviewed.
Result: approved; no blocking issues or warnings.
Acceptance criteria: 7/7 met.
Verified: npm test --workspace @slugkit/template-site -- src/routes/__tests__/admin-users.test.ts, npm run build --workspace @slugkit/template-site, ./scripts/pre-pr.sh, and Forgejo Actions run #241.
Follow-up: waiting for explicit human merge approval.

_Synced from todu comment by @todu on 2026-06-21T16:22:14.829Z_ ### Review update - PR: https://forge.caradoc.com/erik/slugkit/pulls/175 is open and reviewed. - Result: approved; no blocking issues or warnings. - Acceptance criteria: 7/7 met. - Verified: `npm test --workspace @slugkit/template-site -- src/routes/__tests__/admin-users.test.ts`, `npm run build --workspace @slugkit/template-site`, `./scripts/pre-pr.sh`, and Forgejo Actions run #241. - Follow-up: waiting for explicit human merge approval.

erik

2026-06-21 11:42:45 -05:00

closed this issue
added
status:done
and removed
status:inprogress
labels

erik commented

2026-06-21 11:42:46 -05:00

Author

Owner

Synced from todu comment by @todu on 2026-06-21T16:40:08.525Z

Closing summary

PR #175 was merged into main.

Acceptance criteria:

Settings → Site users has a dedicated recovery/bootstrap admin email section showing configured ADMIN_EMAIL — met.
Recovery/bootstrap section states ADMIN_EMAIL is configured from deployment environment and must be changed in deployment config — met.
Matching stored site-user record is handled for context — met by identifying/filtering the configured recovery identity and protecting it from normal table actions; final UI copy intentionally omits stored status/roles per follow-up design feedback.
Normal Site users table does not show configured ADMIN_EMAIL as a normal editable row — met by filtering it out of editable users.
Admins cannot deactivate or demote the configured bootstrap/recovery identity through normal controls — met by server-side add, role-update, and deactivate guards.
Tests cover matching stored ADMIN_EMAIL user — met.
Tests cover ADMIN_EMAIL without stored site user — met.

Verification:

npm test --workspace @slugkit/template-site -- src/routes/__tests__/admin-users.test.ts
npm run build --workspace @slugkit/template-site
./scripts/pre-pr.sh
Forgejo Actions #241 and follow-up #242 passed.

Readiness: READY. Closing task.

_Synced from todu comment by @todu on 2026-06-21T16:40:08.525Z_ ### Closing summary PR #175 was merged into `main`. Acceptance criteria: - Settings → Site users has a dedicated recovery/bootstrap admin email section showing configured `ADMIN_EMAIL` — met. - Recovery/bootstrap section states `ADMIN_EMAIL` is configured from deployment environment and must be changed in deployment config — met. - Matching stored site-user record is handled for context — met by identifying/filtering the configured recovery identity and protecting it from normal table actions; final UI copy intentionally omits stored status/roles per follow-up design feedback. - Normal Site users table does not show configured `ADMIN_EMAIL` as a normal editable row — met by filtering it out of editable users. - Admins cannot deactivate or demote the configured bootstrap/recovery identity through normal controls — met by server-side add, role-update, and deactivate guards. - Tests cover matching stored `ADMIN_EMAIL` user — met. - Tests cover `ADMIN_EMAIL` without stored site user — met. Verification: - `npm test --workspace @slugkit/template-site -- src/routes/__tests__/admin-users.test.ts` - `npm run build --workspace @slugkit/template-site` - `./scripts/pre-pr.sh` - Forgejo Actions #241 and follow-up #242 passed. Readiness: READY. Closing task.

erik commented

2026-06-21 11:42:46 -05:00

Author

Owner

Synced from todu comment by @todu on 2026-06-21T16:39:34.382Z

Review update

PR #175 follow-up UI refinements were pushed and reviewed.
Recovery admin email section moved to the bottom and no longer shows stored status/roles.
Users table now uses Email, Name, Role, and Status columns; role dropdowns keep the Update button and use autocomplete="off" to avoid stale browser-restored role selections.
Result: approved; no blocking issues or warnings.
Verified: targeted admin-users test, ./scripts/pre-pr.sh, and Forgejo Actions run #242.

_Synced from todu comment by @todu on 2026-06-21T16:39:34.382Z_ ### Review update - PR #175 follow-up UI refinements were pushed and reviewed. - Recovery admin email section moved to the bottom and no longer shows stored status/roles. - Users table now uses Email, Name, Role, and Status columns; role dropdowns keep the Update button and use `autocomplete="off"` to avoid stale browser-restored role selections. - Result: approved; no blocking issues or warnings. - Verified: targeted admin-users test, `./scripts/pre-pr.sh`, and Forgejo Actions run #242.