From e8216b14e9ffe7a263c11e452d71055a86d0e9ac Mon Sep 17 00:00:00 2001 From: Midas Wollinger Date: Thu, 20 Aug 2026 15:47:50 +0200 Subject: [PATCH] fix db --- app/db/migrations/0006_tenants.sql | 46 +++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/app/db/migrations/0006_tenants.sql b/app/db/migrations/0006_tenants.sql index 823226a..9399b76 100644 --- a/app/db/migrations/0006_tenants.sql +++ b/app/db/migrations/0006_tenants.sql @@ -38,16 +38,42 @@ CREATE TABLE IF NOT EXISTS tenant_admins ( ); CREATE INDEX IF NOT EXISTS idx_tenant_admins_user ON tenant_admins(user_id); -ALTER TABLE host_groups ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id); -ALTER TABLE user_groups ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id); -ALTER TABLE ssh_keys ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id); --- api_tokens: bewusst NICHT nullable -- jedes Token (auch von einem --- Super-Admin erzeugte) ist genau einem Mandanten zugeordnet. Ein Token ist --- (wie schon vor dieser Migration) nie is_admin=True; ohne verpflichtenden --- Mandantenbezug waere unklar, welche Mandanten-Ressourcen es sehen darf -- --- lieber explizit pro Mandant ein Token ausstellen als eine mehrdeutige --- "gilt ueberall"-Sonderregel einzufuehren (Prinzip: fail closed). -ALTER TABLE api_tokens ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id); +-- WICHTIG zu ALTER TABLE ADD COLUMN + REFERENCES in SQLite: eine per ALTER +-- TABLE nachtraeglich hinzugefuegte Spalte mit REFERENCES-Klausel darf NUR +-- einen NULL-Default haben ("Cannot add a REFERENCES column with non-NULL +-- default value") -- UND eine NOT NULL-Klausel wiederum erfordert einen +-- Default ungleich NULL. Beides gleichzeitig (NOT NULL DEFAULT 1 REFERENCES +-- ...) ist beim nachtraeglichen Hinzufuegen einer Spalte also grundsaetzlich +-- unmoeglich (nur bei CREATE TABLE erlaubt) -- ein vollstaendiger +-- Tabellen-Rebuild (SQLite-12-Schritte-Verfahren) waere die einzige +-- Alternative, wird hier aber bewusst vermieden, um bestehende +-- Produktivdaten nicht bei jedem Deployment einem Rebuild-Risiko +-- auszusetzen. Stattdessen: Spalte NULLABLE mit REFERENCES hinzufuegen, +-- bestehende Zeilen sofort auf den Standard-Mandanten (id=1) zurueckfuellen. +-- Die Nicht-NULL-Garantie wird stattdessen ausschliesslich anwendungsseitig +-- durchgesetzt: JEDER Insert-Pfad in app/admin/routes.py ermittelt +-- tenant_id ueber _resolve_write_tenant() (nie NULL, siehe app/tenancy.py) -- +-- bestehende Zeilen sind durch das Backfill unten ebenfalls nie NULL. +ALTER TABLE host_groups ADD COLUMN tenant_id INTEGER REFERENCES tenants(id); +UPDATE host_groups SET tenant_id = 1 WHERE tenant_id IS NULL; + +ALTER TABLE user_groups ADD COLUMN tenant_id INTEGER REFERENCES tenants(id); +UPDATE user_groups SET tenant_id = 1 WHERE tenant_id IS NULL; + +ALTER TABLE ssh_keys ADD COLUMN tenant_id INTEGER REFERENCES tenants(id); +UPDATE ssh_keys SET tenant_id = 1 WHERE tenant_id IS NULL; + +-- api_tokens: konzeptionell bewusst NICHT nullable -- jedes Token (auch von +-- einem Super-Admin erzeugte) ist genau einem Mandanten zugeordnet. Ein +-- Token ist (wie schon vor dieser Migration) nie is_admin=True; ohne +-- verpflichtenden Mandantenbezug waere unklar, welche Mandanten-Ressourcen +-- es sehen darf -- lieber explizit pro Mandant ein Token ausstellen als eine +-- mehrdeutige "gilt ueberall"-Sonderregel einzufuehren (Prinzip: fail +-- closed). Schema-technisch aus obigem Grund dennoch nullable + Backfill; +-- app/admin/routes.py::create_api_token() setzt tenant_id auf jedem +-- Insert-Pfad immer explizit. +ALTER TABLE api_tokens ADD COLUMN tenant_id INTEGER REFERENCES tenants(id); +UPDATE api_tokens SET tenant_id = 1 WHERE tenant_id IS NULL; -- users.home_tenant_id: rein informativ/UX -- der Mandant, "fuer" den ein -- Benutzer angelegt wurde (automatisch gesetzt, wenn ein Mandanten-Admin den