tessera-ctl/docs/mandantentrennung-etappe3-auftrag.md

Mandantentrennung — Etappe 3: Auftrag fuer die naechste Sitzung

Geschrieben am 2026-09-11 am Ende der Sitzung, die Etappe 2 abgeschlossen hat. Zweck: Eine frische Sitzung soll Etappe 3 ohne Rueckfrage und ohne Neuermittlung der Grundlagen beginnen koennen. Alles hier ist gemessen, nicht erinnert.

Randbedingungen vom User (2026-09-11)

• Dienstag, 2026-09-15, geht die erste voll funktionsfaehige Version live. Live-Gehen braucht den Schalter NICHT — heute laeuft alpha mit dem BYPASSRLS-Stand und einem Mandanten, und das ist fuer den Betrieb unerheblich. Etappe 3 darf das Live-Gehen nicht blockieren.
• Nicht nachfragen. Alles machen, was ohne den User geht. Was nicht ohne ihn geht, am Ende benennen.
• Beim Scharfschalten (Etappe 4) anhalten und fragen. Das ist die einzige Ausnahme, und sie steht seit dem 2026-09-09.
• Nach jedem abgeschlossenen Durchlauf pushen (git push genuegt, die Push-URL zeigt auf localhost:3002).

Stand beim Einstieg

• Etappe 2 abgeschlossen, alle zwoelf Bereiche gebunden, jeder einzeln verifiziert. Endstand 994 Tests / 62 Dateien, 137 Live-Pruefungen, Klassifikation 65 Paare / 68 ungebunden / 178 gebunden.
• WINDOWS #27 (Relations-Blindstelle der Bestandsaufnahme) ist als Quick-Task 260911-mkj in Arbeit oder abgeschlossen — git log und .planning/quick/260911-mkj-*/ pruefen. Nach dessen Abschluss: 72 Paare.
• Der Schalter ist AUS. DATABASE_URL zeigt auf Rolle tessera.

Die zwei Produktentscheidungen (User, 2026-09-10)

1. Anmeldenamen pro Mandant eindeutig, nicht plattformweit. m.schmidt darf es bei Firma A und Firma B geben.
2. Kollegen derselben Firma strikt getrennt. Jeder sieht nur seine eigenen gespeicherten Suchen, Favoriten, Dashboard-Anordnung.

Etappe 3 in drei Teilen — empfohlene Reihenfolge

3b zuerst: Benutzerdimension in den Regeln

Warum zuerst: reiner Datenbank- und Helfer-Umbau, beruehrt den Anmeldeweg NICHT, und schliesst die Klasse von Befunden, die in sieben Bereichen als "Policy hat keine Benutzerdimension" festgehalten wurde.

Gemessene Grundlagen:

• forTenant(prisma, tenantId) in apps/api/src/prisma/prisma-tenant.extension.ts:111 setzt genau EINE Sitzungsvariable: set_config('app.current_tenant', ..., true). current_tenant_id() ist in 20260618112133_rls_policies definiert.
• Es gibt KEIN app.current_user und KEIN current_user_id() — nirgends in Migrationen oder Quelltext.
• 14 Modelle tragen eine userId-Spalte: CalendarSource, DashboardLayout, FavoriteLink, GroupMembership, ModuleGrant, PasswordResetToken, SearchProvider, TenderEmailConfig, TenderMatch, TenderNotificationPref, TenderRssFeedSource, TenderSavedSearch, TenderTriage, WidgetInstance. NICHT alle davon sind "persoenliche Daten": GroupMembership und ModuleGrant sind Verwaltungsobjekte (ein Admin darf sie fuer andere sehen), PasswordResetToken ist ein Anmelde-Artefakt, TenderMatch wird vom Hintergrunddienst je Treffer geschrieben. Die Benutzerdimension gehoert auf die ZEHN echten Nutzerobjekte; welche das sind, ist je Modell zu entscheiden und am Ort zu begruenden — Vorgabe aus den Bereichs-Kritiken: CalendarSource, DashboardLayout, FavoriteLink, SearchProvider (persoenliche Zeilen), TenderEmailConfig, TenderNotificationPref, TenderRssFeedSource (persoenliche Zeilen), TenderSavedSearch, TenderTriage, WidgetInstance.
• Der Anwendungscode trennt heute bereits korrekt nach Benutzer (in jedem Bereich stichprobenartig belegt, Besitzpruefungen in ldap/dkv/dashboard/ calendar/favorites/auth als Tests festgenagelt). Die Datenbank tut es nicht. Das zweite Netz fehlt.

Bauform, an der es sich zu orientieren gilt:

• Zweite Sitzungsvariable app.current_user, Funktion current_user_id() nach dem Muster von current_tenant_id().
• forTenant() bekommt einen optionalen dritten Parameter userId (oder ein Schwesterhelfer forTenantAndUser() — Entscheidung im Plan, mit Begruendung; Praezedenz fuer "Helfer erweitern statt zweiten bauen" ist withTenantTransaction()). Hintergrunddienste und Verwaltungswege rufen weiter ohne userId; nur die Nutzer-CRUD-Wege setzen ihn.
• Regeln der zehn Tabellen: Lesen tenantId = current_tenant_id() AND (current_user_id() IS NULL OR userId = current_user_id()) — damit ein Aufruf OHNE gesetzten Benutzer (Admin, Hintergrunddienst) weiter alles des Mandanten sieht. Schreiben analog. Das IS-NULL-Muster ist die Form aus der #19-Loesung (260910-jab), dort fuer plattformweite Zeilen.
• Messen, nicht annehmen: rls-scratch-check.mjs bekommt einen Abschnitt je umgestellter Tabelle, ueber den GENERIERTEN Client, mit schemagleicher Wegwerf-Tabelle (Spaltenvergleich zur Laufzeit — createdAt/updatedAt-Falle aus 260910-krx).
• Die drei loch-behauptenden Pruefungen aus tenders und dashboard ("Policies haben keine Benutzerdimension", z. B. tendersavedsearch-fremder-nutzer-desselben-mandanten-sichtbar) UMDREHEN, nicht loeschen — Muster aus 260910-jab.

3a danach: Anmeldenamen pro Mandant

Warum danach: aendert das Schema UND den Anmeldeweg, ist der riskanteste Teil, und braucht 3b nicht.

Gemessene Grundlagen:

• User.username String @unique und User.email String? @unique (schema.prisma:31-32) — plattformweit.
• Die drei SECURITY-DEFINER-Funktionen in 20260909160000_auth_lookup_functions: auth_lookup_user_by_username(p_username), auth_lookup_user_by_email(p_email), auth_lookup_reset_token(p_token). Jede sucht ueber EINE Gleichheitsbedingung mit LIMIT 1. Der Mandant kommt erst AUS der gefundenen Zeile.
• Aufrufer: auth.service.ts:95,110,218 und user.service.ts:33.
• Bewusst ungebundene Stellen, die genau an dieser plattformweiten Eindeutigkeit haengen und mit 3a fallen: ldap.service.ts resolveEmailForWrite (260909-ipc, Befund A), die P2002-Kollisionskette in tenders/user (unsichtbare Zeile -> falsches "frei" -> harter Fehler), user.service.ts findByUsername (null Aufrufer, 260910-das).

Bauform:

• Schema: @@unique([tenantId, username]), @@unique([tenantId, email]) statt @unique. Migration mit Datenpruefung davor (heute ein Mandant, also keine Kollision moeglich — trotzdem messen).
• Der Anmeldeweg muss den Mandanten kennen, BEVOR er die Zeile sucht. Zwei uebliche Wege: (i) eigene Adresse je Mandant (Subdomain firma-a.tessera.ctl.de -> Mandant aus dem Host), (ii) Mandantenwahl beim Login. Das ist eine Produktfrage, die der User NICHT beantwortet hat. Empfehlung fuer die Planung: (i), weil Tessera hinter Nginx Proxy Manager laeuft und Subdomains dort trivial sind, und weil (ii) den Anmeldenamen als Geheimnis schwaecht. Wenn die Planung das anders sieht, ist es einer der Punkte, die am Ende dem User genannt werden.
• Die drei Funktionen bekommen eine zweite Gleichheitsbedingung (p_tenant_id) — ENGER, nicht weiter. Die Kopfkommentare in docs/mandantentrennung-datenbankrolle.md nachziehen.
• Bis der Mandant vor der Suche bekannt ist, laesst sich 3a NICHT scharfschalten. Deshalb ist 3a fuer Dienstag NICHT noetig: mit einem Mandanten ist plattformweit = pro Mandant.

3c zuletzt: Systemkontext fuer die Hintergrunddienste

Sechs Faelle, alle im Abschnitt "Der Hintergrunddienst als Falle" der Klassifikation und in den Bereichs-Kritiken:

• dkv-scheduler / loadAnyActiveConfigForScheduler() (WINDOWS #21) — heute bereits falsch (willkuerlicher Mandant).
• mail.module / loadAnySmtpConfigForStartupTransport() (WINDOWS #30) — dieselbe Form.
• ldap-config.service getAllActiveConfigs() / onApplicationBootstrap — heute korrekt, verstummt spaeter.
• tender-digest.scheduler, tender-matching.service — uebergreifende Haelften an Etappe 3 uebergeben (260909-laa).
• admin-seed.service ensureDefaultGroupsForAllTenants — Schleife ueber alle Mandanten, Rumpf bereits gebunden.

Bauform: Ein benannter Systemkontext (z. B. forSystem(prisma)), der eine DRITTE Sitzungsvariable app.system_context = 'true' setzt, und Regeln, die diesen Kontext fuer LESENDE Zugriffe zulassen (OR current_setting( 'app.system_context', true) = 'true'). Schreibzugriffe innerhalb der Schleife bleiben je Mandant gebunden. Der DKV- und der SMTP-Startpfad werden dann zu "einmal-abfragen-viele-bedienen" — das ist die in 07-04 zurueckgestellte Mehrmandanten-Planung und der einzige echte Funktionsausbau in Etappe 3.

Was NICHT ohne den User geht

• 3a, Weg (i) vs. (ii): wie der Mandant beim Login bestimmt wird.
• Etappe 4: Scharfschalten. Ausdruecklich.

Werkzeuge und Fallen (aus Etappe 2, jede mindestens einmal erlebt)

• git status ist die Wahrheit, nicht der Agentenbericht. Zwei Agenten brachen am Sitzungslimit NACH getaner Arbeit ab.
• Ein grep -c ist eine Behauptung. Vier Kopfzahlen schrumpften beim Hineinsehen.
• Eine nicht committete Messung ist kein Beleg (zweimal passiert).
• Zusammenfassungen behaupten N, wo N-1 geliefert ist (zweimal passiert).
• Handgepflegte Dokumentstellen werden uebersprungen — Gates ABLEITEN.
• Roh-SQL ist nicht der generierte Client (Wegwerf-Tabelle ohne createdAt/updatedAt).
• Ein Plan-Pruefer, der "plausibel" sagt, hat nicht geprueft.
• git add mit mehreren Pfaden, einer davon geloescht, scheitert still.
• Der Datenbank-Container hat keinen Host-Port: IP per docker inspect frisch ermitteln, tessera:tessera_dev. Prisma-Binary aus apps/api/node_modules/.bin/prisma, NICHT npx prisma (zieht Prisma 8).
• Kein mailhog lokal — ENOTFOUND mailhog ist Umgebung, kein Defekt.
• Backticks in Heredoc-Python werden von der Shell ausgewertet — Skripte in eine Datei schreiben, dann ausfuehren.

Einstieg

/gsd-resume-work, dann /gsd-quick fuer 3b mit --validate. Planer, Plan-Pruefer, Executor, Verifizierer — die Kette vollstaendig, jede Lieferung wurde in Etappe 2 vom jeweils naechsten Schritt gefangen, nie vom eigenen.