mirror of
https://github.com/screentinker/screentinker.git
synced 2026-06-15 02:33:15 -06:00
66c95bb331
The #18 user-delete bug was the first symptom of a broader gap: 13 tables reference workspaces(id) (and activity_log also organizations(id)) with NO ACTION, so deleting a workspace or organization fails the same FK wall once it holds any content. SQLite can't ALTER an FK action, so this migration rebuilds each table (the create-copy-rename pattern the assignments/schedules migrations already use), changing only the tenant FK clause: workspace_id -> ON DELETE CASCADE (resources belong to the workspace) activity_log.workspace_id / organization_id -> ON DELETE SET NULL (keep audit) user_id FKs are intentionally left as-is - user deletion stays handled app-side by lib/user-deletion.js (the #18 fix). - lib/tenant-cascade-migration.js: pure, idempotent core (table-existence guarded; transforms the stored CREATE text, copies rows verbatim, recreates indexes; fixes activity_log's AUTOINCREMENT sequence; baseline-vs-after foreign_key_check so pre-existing orphan rows don't abort it but a botched rebuild does). - db/database.js: boot wrapper owns the pre-migration snapshot + process.exit on failure, matching the other heavy migrations. Tests (node:test): reproduces the workspace-delete FK failure, applies the migration, verifies FK actions (CASCADE / SET NULL), index recreation, data preserved, and that workspace/org delete now cascades (activity_log preserved). Full suite 27/27. Verified on a copy of a real DB: 13 tables rebuilt, integrity_check ok, workspace delete cascades, no new FK violations. |
||
|---|---|---|
| .. | ||
| command-queue.js | ||
| permissions.js | ||
| socket-rooms.js | ||
| tenancy.js | ||
| tenant-cascade-migration.js | ||
| user-deletion.js | ||