erik/slugkit

Fork

You've already forked slugkit

Code Issues 6 Pull requests Projects Releases 6 Packages Wiki Activity Actions

Introduce site users and access roles #146

New issue

Closed

opened 2026-06-16 21:52:28 -05:00 by erik · 3 comments

erik commented

2026-06-16 21:52:28 -05:00

Owner

Copy link

Goal

Introduce a stored site user model that separates bootstrap owner access, management permissions, and future protected-content viewing from the public ActivityPub author identity, and make the first slice usable through minimal admin user management.

Requirements

Treat ADMIN_EMAIL as bootstrap or recovery access rather than the permanent user model.
Add stored site users that can authenticate independently of deployment environment variables after bootstrap.
Support management roles or capabilities so some users can administer the site while others may only view protected content later.
Leave room for protected content access without making all logged-in users admins.
Keep ActivityPub actor identity separate from login users; users manage or view the site, while the primary ActivityPub actor remains the public local author/publisher.
Preserve existing local development login behavior while introducing the new model incrementally.
Persist successful bootstrap/recovery logins as site users with admin capability.
Add a minimal admin user-management surface where admin users can list site users, add users, assign admin or viewer roles, and deactivate users.
Protect site-user management with admin capability checks.
Document the distinctions between bootstrap owner, site users, management permissions, protected-content access, and ActivityPub actor identity.
Keep the first implementation as a small vertical slice.

Acceptance criteria

The codebase has a clear stored site user model.
Admin access is represented as a role/capability on a site user, not conflated with public ActivityPub authorship.
The model includes a non-admin viewer role or equivalent to support protected-content viewing later.
ADMIN_EMAIL behavior is documented as bootstrap/recovery-oriented rather than the sole long-term admin identity.
Existing admin login flows continue to work during the transition.
Successful bootstrap/recovery login creates or updates an admin site user.
Admin users can list, add, role-assign, and deactivate site users through a minimal admin UI.
Non-admin users are represented but cannot access admin-only user management.
ActivityPub actor identity remains separate from site users.
Tests cover implemented user/role behavior and admin user-management access.
Relevant lint/test checks pass.

Dependencies

None

## Goal Introduce a stored site user model that separates bootstrap owner access, management permissions, and future protected-content viewing from the public ActivityPub author identity, and make the first slice usable through minimal admin user management. ## Requirements - Treat `ADMIN_EMAIL` as bootstrap or recovery access rather than the permanent user model. - Add stored site users that can authenticate independently of deployment environment variables after bootstrap. - Support management roles or capabilities so some users can administer the site while others may only view protected content later. - Leave room for protected content access without making all logged-in users admins. - Keep ActivityPub actor identity separate from login users; users manage or view the site, while the primary ActivityPub actor remains the public local author/publisher. - Preserve existing local development login behavior while introducing the new model incrementally. - Persist successful bootstrap/recovery logins as site users with admin capability. - Add a minimal admin user-management surface where admin users can list site users, add users, assign `admin` or `viewer` roles, and deactivate users. - Protect site-user management with admin capability checks. - Document the distinctions between bootstrap owner, site users, management permissions, protected-content access, and ActivityPub actor identity. - Keep the first implementation as a small vertical slice. ## Acceptance criteria - [ ] The codebase has a clear stored site user model. - [ ] Admin access is represented as a role/capability on a site user, not conflated with public ActivityPub authorship. - [ ] The model includes a non-admin `viewer` role or equivalent to support protected-content viewing later. - [ ] `ADMIN_EMAIL` behavior is documented as bootstrap/recovery-oriented rather than the sole long-term admin identity. - [ ] Existing admin login flows continue to work during the transition. - [ ] Successful bootstrap/recovery login creates or updates an admin site user. - [ ] Admin users can list, add, role-assign, and deactivate site users through a minimal admin UI. - [ ] Non-admin users are represented but cannot access admin-only user management. - [ ] ActivityPub actor identity remains separate from site users. - [ ] Tests cover implemented user/role behavior and admin user-management access. - [ ] Relevant lint/test checks pass. ## Dependencies - None

erik added the

labels

2026-06-16 21:52:28 -05:00

erik added

status:inprogress

and removed

status:active

labels

2026-06-20 07:37:04 -05:00

erik commented

2026-06-20 07:37:05 -05:00

Author

Owner

Copy link

Synced from todu comment by @todu on 2026-06-20T12:35:53.607Z

Update

Started implementation on branch feat/task-4ea105da-site-users-roles.
Expanded scope is approved: stored site users/roles, bootstrap admin persistence, minimal /admin/users management, admin capability checks, docs, and tests.

_Synced from todu comment by @todu on 2026-06-20T12:35:53.607Z_ ### Update - Started implementation on branch `feat/task-4ea105da-site-users-roles`. - Expanded scope is approved: stored site users/roles, bootstrap admin persistence, minimal `/admin/users` management, admin capability checks, docs, and tests.

erik

2026-06-20 07:48:00 -05:00

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

erik commented

2026-06-20 07:48:01 -05:00

Author

Owner

Copy link

Synced from todu comment by @todu on 2026-06-20T12:46:42.975Z

Closing summary

Task close gate: READY

Acceptance criteria verified:

Stored site user model added with site_users, site_user_roles, and auth/site-users.ts helpers.
Admin access is now a stored site-user admin role/capability, separate from ActivityPub authorship.
Non-admin viewer role added for future protected-content access.
ADMIN_EMAIL documented as bootstrap/recovery access in auth/README.md.
Existing login flows remain covered by auth route tests.
Successful bootstrap/recovery magic-link login creates or updates an admin site user.
/admin/users lets admins list, add, assign admin/viewer, and deactivate site users.
Viewer/non-admin sessions cannot access admin-only user management.
ActivityPub actor identity remains separate in docs and code paths.
Tests cover user/role behavior and admin user-management access.
Verification passed: npm run build --workspace @slugkit/template-site, targeted template-site tests, ./scripts/pre-pr.sh, and Forgejo Actions run #227.

PR #162 merged into main: #162

_Synced from todu comment by @todu on 2026-06-20T12:46:42.975Z_ ### Closing summary Task close gate: READY Acceptance criteria verified: - Stored site user model added with `site_users`, `site_user_roles`, and `auth/site-users.ts` helpers. - Admin access is now a stored site-user `admin` role/capability, separate from ActivityPub authorship. - Non-admin `viewer` role added for future protected-content access. - `ADMIN_EMAIL` documented as bootstrap/recovery access in `auth/README.md`. - Existing login flows remain covered by auth route tests. - Successful bootstrap/recovery magic-link login creates or updates an admin site user. - `/admin/users` lets admins list, add, assign `admin`/`viewer`, and deactivate site users. - Viewer/non-admin sessions cannot access admin-only user management. - ActivityPub actor identity remains separate in docs and code paths. - Tests cover user/role behavior and admin user-management access. - Verification passed: `npm run build --workspace @slugkit/template-site`, targeted template-site tests, `./scripts/pre-pr.sh`, and Forgejo Actions run #227. PR #162 merged into `main`: https://forge.caradoc.com/erik/slugkit/pulls/162

erik commented

2026-06-20 07:48:01 -05:00

Author

Owner

Copy link

Synced from todu comment by @todu on 2026-06-20T12:43:53.646Z

Review update

PR: #162 is open and reviewed.
Result: approved; no blocking issues or warnings.
Verified: npm run build --workspace @slugkit/template-site, targeted template-site tests for site users/admin users/auth/migrations/existing admin routes, ./scripts/pre-pr.sh, and Forgejo Actions run #227.
Acceptance: 11/11 criteria met.
Follow-up: waiting for explicit human merge approval.

_Synced from todu comment by @todu on 2026-06-20T12:43:53.646Z_ ### Review update - PR: https://forge.caradoc.com/erik/slugkit/pulls/162 is open and reviewed. - Result: approved; no blocking issues or warnings. - Verified: `npm run build --workspace @slugkit/template-site`, targeted template-site tests for site users/admin users/auth/migrations/existing admin routes, `./scripts/pre-pr.sh`, and Forgejo Actions run #227. - Acceptance: 11/11 criteria met. - Follow-up: waiting for explicit human merge approval.

No Branch/Tag specified

main

release/slug-cli-v0.5.0

release/slug-cli-v0.4.0

release/slug-cli-v0.3.0

release/slug-cli-v0.2.0

release/slug-cli-v0.1.2

release/slug-cli-v0.1.1

feat/task-47be19ea-api-meta-route

feat/task-51eaa27f-swagger-api-docs

feat/task-0dbd25d3-site-config-homepage

feat/task-69937fe4-sqlite-migrations

feat/task-a3cd5595-cli-foundation

feat/task-c272cbda-openapi-health

feat/task-d6397b57-template-foundation

v0.5.0

v0.4.0

v0.3.0

v0.2.0

v0.1.2

v0.1.1

Labels

Clear labels

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

erik/slugkit#146

Reference in a new issue

Repository

erik/slugkit

Title

Body

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

Rows
Columns