Phase 12.1: User plugin admin screens - Discussion Log
Audit trail only. Do not use as input to planning, research, or execution agents.
Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
Date: 2026-10-04
Phase: 12.1-user-plugin-admin-screens
Areas discussed: Impersonate and convert-guest, Group membership and the admin group, User actions and trashed users, Fields the Go model lacks, Release
Impersonate and convert-guest
Should 'impersonate user' be part of this phase?
| Option |
Description |
Selected |
| Out of scope (Recommended) |
PHP impersonation is session-based and never reaches the JWT-driven Nuxt app; permission not registered |
|
| Out, but register the permission |
No action, but golem15.users.impersonate_user is registered so imported roles stay valid |
✓ |
| In scope: mint a user JWT |
Admin gets a short-lived frontend token for the user, with audit; needs security review and a Nuxt entry point |
|
User's choice: Out, but register the permission
What happens to convert-guest and the guest concept?
| Option |
Description |
Selected |
| Drop it entirely (Recommended) |
No action, no is_guest column or list column, no guest hint |
✓ |
| Add is_guest, skip the action |
Column and invisible list column for schema fidelity, no popup |
|
| Port convert-guest fully |
Column, popup with group choice, optional registration mail |
|
User's choice: Drop it entirely
Notes: The application never creates guests and the Go users table has no is_guest.
Group membership and the admin group
Which backend permission is required to change a user's group membership?
| Option |
Description |
Selected |
| Extra permission for privileged groups (Recommended) |
access_users for ordinary groups; privileged groups need a new permission, server-side |
✓ |
| access_users only (PHP parity) |
Any user editor can put a user in any group, including admin |
|
| New permission for all membership changes |
Any users_groups change needs a dedicated permission |
|
How does the plugin know which groups are privileged?
| Option |
Description |
Selected |
| Config list, default [admin] (Recommended) |
golem15.user config key listing privileged codes |
✓ |
Hard-coded code admin |
Only admin is privileged, no config |
|
| A flag column on user_groups |
New boolean on the group row |
|
How should the User Groups screen guard privileged codes?
| Option |
Description |
Selected |
| Privileged codes need the extra permission (Recommended) |
Create with, rename to/from, and delete of a privileged code need the extra permission |
✓ |
| Code is read-only after create |
Code never changes once saved |
|
| No guard (PHP parity) |
access_groups edits any group including its code |
|
How do privileged groups behave for an admin without the permission?
| Option |
Description |
Selected |
| Shown but locked, 403 on tamper (Recommended) |
Visible and disabled; a tampered save is refused and changes nothing |
✓ |
| Hidden from the options |
Left out of the field; existing memberships kept |
|
| Whole save refused, no UI hint |
Field looks normal; validation error if a privileged group changed |
|
User actions and trashed users
How should the Go admin carry the six bulk actions and three record actions?
| Option |
Description |
Selected |
| Extend cabana generically (Recommended) |
Framework gains declared bulk actions and record actions |
✓ |
| Plugin-side with existing pieces |
Widget buttons on the form; bulk actions dropped except delete |
|
| Record actions only, bulk later |
Record buttons now, bulk to the backlog |
|
Delete semantics and trashed users
| Option |
Description |
Selected |
| PHP parity (Recommended) |
Trashed users listed; deactivate = soft delete, restore, delete = permanent |
✓ |
| Parity, but force delete needs confirmation by email |
Same, plus typing the user's email before a permanent delete |
|
| Soft delete only |
No permanent delete in the admin |
|
Where do the status and the actions live (PHP has a preview screen)?
| Option |
Description |
Selected |
| On the update form (Recommended) |
Status notice and conditional action buttons on the update form; no preview |
|
| Add a preview screen to the framework |
cabana gains Winter's preview context with its own toolbar |
✓ |
| Actions always visible, no status notice |
All buttons shown regardless of state |
|
User's choice: Add a preview screen to the framework
Notes: Chosen over the recommended lighter option; PHP parity of the admin experience is the bar.
How should the list show user state?
| Option |
Description |
Selected |
| Generic row state in the framework (Recommended) |
Controller returns a state per row from a fixed set; SPA styles with tokens |
✓ |
| A status column |
One computed Status column, no row styling |
|
| Both |
Row state and a status column |
|
Fields the Go model lacks
Port the frontend Permissions tab (FrontendPermissionEditor)?
| Option |
Description |
Selected |
| Leave out, defer (Recommended) |
No Permissions tab; its own later phase |
|
| Port the editor |
Registry table, users.permissions, editor on both forms |
✓ |
User's choice: Port the editor
How far does the frontend-permissions port go?
| Option |
Description |
Selected |
| Storage, editor and resolver (Recommended) |
Table, column, editor, and a Go getMergedPermissions equivalent |
✓ |
| Storage and editor only |
No resolver until a project needs it |
|
| Also a plugin-declared registry |
Plugins declare frontend permissions in Go, synced at boot |
|
How should the editor be built?
| Option |
Description |
Selected |
| Built-in framework field type (Recommended) |
permissioneditor in cabana and the SPA, reusable for backend roles later |
✓ |
| Extend the widget contract |
type: widget carries a structured value; plugin ships a custom element |
|
Block mail (MailBlocker)
| Option |
Description |
Selected |
| Leave out, defer (Recommended) |
No checkbox; a mail feature, not an admin screen |
|
| Port MailBlocker now |
Table, form flag, mailer check |
|
User's choice: (free text) "Leave out, write in todos to implement together with mailing development (so together with mail settings, templates etc)"
Notes: Todo written: .planning/todos/pending/mailblocker-with-mailing.md.
username and last_seen
| Option |
Description |
Selected |
| Drop both from the YAML (Recommended) |
Only columns the Go model has |
|
| Add last_seen, drop username |
Additive last_seen updated by the auth path |
✓ |
| Add both columns |
Full schema fidelity |
|
Create form: password, invite, avatar
| Option |
Description |
Selected |
| All of it (Recommended) |
Password + confirmation, reset on update, send_invite mail, avatars on users and organisations |
✓ |
| Password and avatar, no invite |
No invitation mail |
|
| Password only |
No invite, no avatar fields |
|
Release
| Option |
Description |
Selected |
| Framework first, tagged v0.1.2 (Recommended) |
Framework work lands first and is tagged; plugin builds on the tag |
✓ (as v0.1.3) |
| One phase, no tag |
Ship together through the local replace |
|
| Split the framework work into its own phase |
Insert 12.3 for the cabana features |
|
User's choice: (free text) "Framework first, but i belive it's v0.1.3, v0.1.2 already exists"
Notes: Verified with git tag: v0.1.2 exists, so the tag is v0.1.3.
Claude's Discretion
- The extra permission's code, label and tab; the privileged-list config key name.
- YAML keys and Go interface names for bulk actions, record actions, preview and row state.
- The row state set and styling; preview screen contents beyond hints, fields and actions.
- When
last_seen is written; force-delete cleanup details.
- Plan count and split (subject to the plan-count checkpoint).
Deferred Ideas
- Impersonation by minting a short-lived user JWT.
- MailBlocker with the mailing work (todo written).
- Guests and convert-guest;
username and login by username.
- Plugin-declared frontend permission registry;
permissioneditor for backend roles.
- The user plugin's Settings screen.
