feat: user and group management API and UI #88

New Issue

forbes · 2026-02-14T14:52:55Z

forbes commented

2026-02-14 14:52:55 +00:00

Ref: docs/ROADMAP.md § Multi-User Enablement

Add admin-facing user and group management beyond the current auto-provisioned auth flow.

Requirements

API Endpoints — Users

GET /api/admin/users — list all users with status, role, last login (admin)
GET /api/admin/users/{id} — get user detail (admin)
PATCH /api/admin/users/{id} — update role, active status, display name (admin)
DELETE /api/admin/users/{id} — deactivate user (admin)

API Endpoints — Groups

GET /api/groups — list groups (viewer+)
POST /api/groups — create group (admin)
GET /api/groups/{id} — get group with members (viewer+)
PUT /api/groups/{id} — update group name/description (admin)
DELETE /api/groups/{id} — delete group (admin)
POST /api/groups/{id}/members — add user to group (admin)
DELETE /api/groups/{id}/members/{userId} — remove user from group (admin)

Database

Add groups table: id, name, description, created_at
Add group_members table: group_id, user_id (composite PK)
Migration for both tables

Web UI

Admin settings page: user list with role dropdown, active toggle
Group management page: create/edit groups, add/remove members
User profile shows group memberships

Notes

Groups are foundational for folder/state permissions (future issue)
Current role model (admin/editor/viewer) remains — groups are additive, not a replacement
LDAP/OIDC users are auto-provisioned on first login; admins can adjust role afterward

Ref: docs/ROADMAP.md § Multi-User Enablement Add admin-facing user and group management beyond the current auto-provisioned auth flow. ## Requirements ### API Endpoints — Users - `GET /api/admin/users` — list all users with status, role, last login (admin) - `GET /api/admin/users/{id}` — get user detail (admin) - `PATCH /api/admin/users/{id}` — update role, active status, display name (admin) - `DELETE /api/admin/users/{id}` — deactivate user (admin) ### API Endpoints — Groups - `GET /api/groups` — list groups (viewer+) - `POST /api/groups` — create group (admin) - `GET /api/groups/{id}` — get group with members (viewer+) - `PUT /api/groups/{id}` — update group name/description (admin) - `DELETE /api/groups/{id}` — delete group (admin) - `POST /api/groups/{id}/members` — add user to group (admin) - `DELETE /api/groups/{id}/members/{userId}` — remove user from group (admin) ### Database - Add `groups` table: `id`, `name`, `description`, `created_at` - Add `group_members` table: `group_id`, `user_id` (composite PK) - Migration for both tables ### Web UI - Admin settings page: user list with role dropdown, active toggle - Group management page: create/edit groups, add/remove members - User profile shows group memberships ### Notes - Groups are foundational for folder/state permissions (future issue) - Current role model (admin/editor/viewer) remains — groups are additive, not a replacement - LDAP/OIDC users are auto-provisioned on first login; admins can adjust role afterward

forbes referenced this issue

2026-02-14 14:53:09 +00:00

feat: folder and state-based permissions #89

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kindred/silo#88