fix db

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);
+-- WICHTIG zu ALTER TABLE ADD COLUMN + REFERENCES in SQLite: eine per ALTER
-ALTER TABLE user_groups ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id);
+-- TABLE nachtraeglich hinzugefuegte Spalte mit REFERENCES-Klausel darf NUR
-ALTER TABLE ssh_keys   ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id);
+-- einen NULL-Default haben ("Cannot add a REFERENCES column with non-NULL
--- api_tokens: bewusst NICHT nullable -- jedes Token (auch von einem
+-- default value") -- UND eine NOT NULL-Klausel wiederum erfordert einen
--- Super-Admin erzeugte) ist genau einem Mandanten zugeordnet. Ein Token ist
+-- Default ungleich NULL. Beides gleichzeitig (NOT NULL DEFAULT 1 REFERENCES
--- (wie schon vor dieser Migration) nie is_admin=True; ohne verpflichtenden
+-- ...) ist beim nachtraeglichen Hinzufuegen einer Spalte also grundsaetzlich
--- Mandantenbezug waere unklar, welche Mandanten-Ressourcen es sehen darf --
+-- unmoeglich (nur bei CREATE TABLE erlaubt) -- ein vollstaendiger
--- lieber explizit pro Mandant ein Token ausstellen als eine mehrdeutige
+-- Tabellen-Rebuild (SQLite-12-Schritte-Verfahren) waere die einzige
--- "gilt ueberall"-Sonderregel einzufuehren (Prinzip: fail closed).
+-- Alternative, wird hier aber bewusst vermieden, um bestehende
-ALTER TABLE api_tokens ADD COLUMN tenant_id INTEGER NOT NULL DEFAULT 1 REFERENCES tenants(id);
+-- 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