feat(quick-260910-jab): listForUser binden, die vier Aufzeichnungen im Quelltext richtigstellen

- TenderRssFeedSourceService.listForUser() nimmt jetzt (userId, tenantId)
  entgegen und laeuft ueber einen gebundenen Klienten (forTenant) — die neue
  Leseregel schliesst plattformweite Zeilen ein, die Reparatur haette den
  ungebundenen Pfad sonst still auf nur die plattformweiten Zeilen reduziert
  (Befund F). createPlatform/remove bleiben bewusst ungebunden, Kommentare an
  der neuen Regel richtiggestellt.
- TendersController.listRssFeeds reicht die Mandantenkennung aus dem
  Aufrufzusammenhang durch.
- Vier Aufzeichnungen im Quelltext (module-access.service.ts,
  groups.service.ts, module-grants.service.ts, rls-coverage.spec.ts) sagen
  jetzt, dass die Datenbankregel seit 20260910120000_rls_widen_membership_
  grant_and_platform_read beide Seiten prueft; die Anwendungspruefungen
  bleiben unveraendert bestehen (zweites Netz, wirkt vor dem Scharfschalten
  als einziger Schutz).
- Zwei-Klienten-Nachweis in module-grants.service.spec.ts ergaenzt (Kommentar,
  warum die beiden Cross-Tenant-Tests nach der Regelaenderung nicht entfallen
  duerfen) und in tender-rss-feed.service.spec.ts umgekehrt (listForUser
  bindet jetzt).
- Rule 1: implizites any beim Destrukturieren in listRssFeeds (feeds ist seit
  der Bindung `any`) mit expliziter Annotation behoben.
- Falsifizierungsnachweis durchgefuehrt: Bindungsaufruf zurueckgenommen,
  genau ein Test wurde rot (AssertionError, 0 statt der erwarteten
  Aufrufe), Ruecknahme rueckgaengig gemacht.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR
This commit is contained in:
2026-09-10 14:35:13 +02:00
parent f4f3115d5a
commit 6b237351e9
9 changed files with 133 additions and 64 deletions
@@ -278,6 +278,15 @@ describe('ModuleGrantsService.grant', () => {
expect(prisma.__grantCount()).toBe(0);
});
// Diese beiden Faelle (T-JTS-03, 260910-jab, Aufgabe 2) beweisen, dass
// assertTargetBelongsToTenant() weiterhin im Anwendungscode scheitert —
// nicht erst in der Datenbank. Seit
// 20260910120000_rls_widen_membership_grant_and_platform_read zieht auch
// die Datenbankregel dieselbe Grenze, aber erst NACH dem Scharfschalten
// (#18 ist weiterhin aus). Wuerde assertTargetBelongsToTenant() im
// Vertrauen auf "das macht jetzt die Datenbank" entfernt, werden GENAU
// diese beiden Faelle rot: der Fake hier hat keine RLS-Policy, nur das
// reale ModuleGrant/Group/User-Schema tut das.
it('wirft NotFoundException für eine groupId aus einem anderen Mandanten und legt nichts an', async () => {
const prisma = makeFakePrisma();
seedBase(prisma);