MEMORY: note admin_users columns added in 0043 + vestigial flags
Deploy to route.crispygoat.com / deploy (push) Successful in 4m0s

This commit is contained in:
Tyler
2026-06-17 11:23:13 -06:00
parent e5db66e74a
commit 52c8a71cd0
+13 -1
View File
@@ -2,7 +2,19 @@
This file captures key context, decisions, fixes, and state from recent work so it survives across conversations. This file captures key context, decisions, fixes, and state from recent work so it survives across conversations.
**Last updated:** 2026-06 (migration reliability + Google sign-in work) **Last updated:** 2026-06 (admin_users schema fix + migration reliability + Google sign-in work)
## 2026-06: `admin_users` schema — extra columns for create-user flow (migration 0043)
The 0001 schema's `admin_users` table has just `name` plus the role-derived `can_manage_*` columns (`can_manage_orders`, `can_manage_products`, `can_manage_stops`, `can_manage_customers`, `can_manage_wholesale`, `can_manage_billing`, `can_manage_settings`, `can_manage_water_log`, `can_manage_time_tracking`, `can_manage_route_trace`, `can_manage_reports`, `can_manage_communications`).
But `src/actions/admin/users.ts` was written against a richer schema: it INSERTs and SELECTs `display_name`, `phone_number`, `brand_id`, `can_manage_pickup/messages/refunds/users`, `active`, `must_change_password`, `auth_provider`, `auth_subject`, `last_login`. Submitting the create-user form produced `column "display_name" of relation "admin_users" does not exist`.
Migration `db/migrations/0043_admin_users_extra_columns.sql` adds all twelve missing columns (`ADD COLUMN IF NOT EXISTS`, re-runnable). `db/schema/brands.ts`'s Drizzle `adminUsers` definition was extended in lockstep.
**Important**: the four extra `can_manage_*` flags (pickup / messages / refunds / users) are **vestigial**`getAdminUser()` in `lib/admin-permissions.ts` derives per-user permissions from the role via `permissionsForRole()`, never reads those columns. They exist only so the create-user form's per-user permission toggles persist; they have no runtime authorization effect. Cleanup target: either (a) read them in the role-derived lookup to support real per-user overrides, or (b) drop them from the form.
The `brand_id` column on `admin_users` is a **denormalization** of the `admin_user_brands` link table (which is the source of truth, and is what `getAdminUser()` reads). The action's `getAdminUsers` joins on `au.brand_id` so keeping the column avoids rewriting that SELECT. Future cleanup can drop the denormalized column and migrate the SELECT to join through the link table.
## 2026-06: CI migration failures on re-deploy (0001_init.sql "already exists") ## 2026-06: CI migration failures on re-deploy (0001_init.sql "already exists")