From 89fb02797a260fdf5306933a4fef5c4347d5c713 Mon Sep 17 00:00:00 2001 From: Schalli Date: Fri, 11 Sep 2026 08:32:41 +0200 Subject: [PATCH] docs: zwei Produktentscheidungen des Users fuer Etappe 3 festgehalten --- .planning/STATE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.planning/STATE.md b/.planning/STATE.md index d70a2dc..0ff6a5f 100644 --- a/.planning/STATE.md +++ b/.planning/STATE.md @@ -424,6 +424,6 @@ sind. Kein Anlass, sie vorher erneut vorzulegen. Last session: 2026-09-10T12:35:40.000Z Resumed: 2026-09-09 — Sitzung ueber /gsd-resume-work fortgesetzt; Einstiegspunkt Etappe 2 (Bereich ldap), Auswahl des Nutzers steht aus. -Stopped at: Quick 260910-jab abgeschlossen — die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) sind geschlossen, VORGEZOGEN auf ausdruecklichen Nutzerwunsch vor die restlichen fuenf offenen Bereiche der Etappe 2 (dashboard 13, calendar 12, tenant 8, favorites 7, auth 5, settings 4 — sechs, nicht fuenf, `settings` war bereits vorher als Reihenfolgebedingung fuer Etappe 4 markiert, Befund K). Diese fuenf/sechs Bereiche messen ab jetzt gegen die NEUEN Regeln aus 20260910120000_rls_widen_membership_grant_and_platform_read. WINDOWS #19 fixed, WINDOWS #24 neu offen (Verwaltungsweg fuer plattformweite Zeilen unter der Anwendungsrolle). Naechster Schritt laut vorheriger Uebergabe: Bereich dashboard (13 Zugriffe), danach wie zuvor geplant. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten. +Stopped at: Quick 260910-jab abgeschlossen — die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) sind geschlossen, VORGEZOGEN auf ausdruecklichen Nutzerwunsch vor die restlichen fuenf offenen Bereiche der Etappe 2 (dashboard 13, calendar 12, tenant 8, favorites 7, auth 5, settings 4 — sechs, nicht fuenf, `settings` war bereits vorher als Reihenfolgebedingung fuer Etappe 4 markiert, Befund K). Diese fuenf/sechs Bereiche messen ab jetzt gegen die NEUEN Regeln aus 20260910120000_rls_widen_membership_grant_and_platform_read. WINDOWS #19 fixed, WINDOWS #24 neu offen (Verwaltungsweg fuer plattformweite Zeilen unter der Anwendungsrolle). Naechster Schritt laut vorheriger Uebergabe: Bereich dashboard (13 Zugriffe), danach wie zuvor geplant. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten. ZWEI PRODUKTENTSCHEIDUNGEN DES USERS VOM 2026-09-10, beide fuer Etappe 3 (nach Abschluss von Etappe 2): (1) ANMELDENAMEN PRO MANDANT EINDEUTIG, nicht plattformweit — m.schmidt darf es bei Firma A und Firma B geben. Folge: `User.username`/`User.email` von `@unique` auf `@@unique([tenantId, username])`/`@@unique([tenantId, email])` umstellen, und der Anmeldeweg muss den Mandanten kennen, BEVOR er die Benutzerzeile sucht (heute kommt der Mandant erst AUS der Zeile; die drei SECURITY-DEFINER-Funktionen aus Etappe 1 suchen ueber den Namen allein). Ueblicher Weg: eigene Adresse je Mandant (Subdomain) oder Mandantenwahl beim Login. Loest zugleich den bewusst ungebundenen `resolveEmailForWrite`-Pfad (ldap) und die Kollisionskette unsichtbar->frei->P2002 (tenders, user). (2) KOLLEGEN DERSELBEN FIRMA STRIKT GETRENNT — jeder sieht nur seine eigenen gespeicherten Suchen, Favoriten, Dashboard-Anordnung. Heute trennt das nur der Anwendungscode; alle Regeln lesen `tenantId = current_tenant_id()` ohne Benutzerdimension. Folge: zweite Sitzungsvariable `app.current_user` samt `current_user_id()`, an jeder Bindungsstelle mitgesetzt, und Benutzerdimension in den Regeln der nutzerbezogenen Tabellen (TenderSavedSearch, TenderTriage, TenderNotificationPref, TenderEmailConfig, TenderRssFeedSource persoenliche Zeilen, DashboardLayout, WidgetInstance, SearchProvider, FavoriteLink, CalendarSource). Danach faengt die Datenbank auch einen Programmierfehler ab, der heute unbemerkt bliebe. Beides eigene Umbauten; Reihenfolge: erst Etappe 2 zu Ende, dann diese beiden als Etappe 3, dann Scharfschalten. Resume file: None Last activity: 2026-09-10 - Completed quick task 260910-jab: Die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) geschlossen