test(quick-260910-exd): Fehlerrichtung fuer module-registry messen, kein Produktivcode
- rls-scratch-check.mjs: achter Abschnitt runModuleRegistryAreaChecks mit 13
benannten Pruefungen gegen die echten, aus den ausgelieferten Migrationen
geschnittenen Regeln (Group/GroupMembership/ModuleGrant/TenantModuleActivation),
neu angelegt nur: Modulkatalog-Tabelle ohne Zeilenschutz, Eindeutigkeitsindex
auf TenantModuleActivation, zwei Direkt-Freigaben, eine fremde Mitgliedschaft
- Alle 66 Pruefungen bestanden (53 bisherige + 13 neue), 810 Tests gruen,
Typpruefung sauber
- docs/mandantentrennung-etappe2-fehlerrichtung.md: neuer Abschnitt
"Bereich module-registry" mit den fuenf Unterabschnitten (m1-m5), inklusive
Praezisierung aus Befund E (Katalogbindung ist HEUTE wirkungslos, nicht
katastrophal — die Bedingung wird als Bedingung notiert) und der
unbeschoenigten Antwort auf die Signalfrage ("keines")
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR
This commit is contained in:
@@ -1248,6 +1248,215 @@ auf den ungebundenen Basisclient zurückgebaut — genau
|
||||
properties of undefined (reading 'update')"; der Rückbau wurde
|
||||
zurückgenommen, derselbe Testlauf danach wieder grün.
|
||||
|
||||
## Bereich module-registry
|
||||
|
||||
Dieser Abschnitt erweitert die Kritikschrift um den Bereich `module-registry`
|
||||
(Quick-Task 260910-exd) und beschreibt ihn zum Zeitpunkt seiner Umstellung.
|
||||
Die Leitfrage aus Abschnitt (a) gilt unverändert weiter — dieser Abschnitt
|
||||
beantwortet sie für den Bereich, der bei JEDER Modulanfrage entscheidet, wer
|
||||
was benutzen darf: die Aktivierungsstufe (`TenantModuleActivation`) und die
|
||||
Freigabestufe (`ModuleGrant`). Bleibt hier eine Abfrage ungebunden, sieht das
|
||||
nach dem Scharfschalten nicht wie ein Fehler aus, sondern wie ein
|
||||
Rechteentzug — die sichtbarste Ausprägung der umgekehrten Fehlerrichtung im
|
||||
gesamten Vorhaben und zugleich die am wenigsten meldungswahrscheinliche.
|
||||
|
||||
### (m1) Die Messung
|
||||
|
||||
Aufgabe 1 hat `apps/api/scripts/rls-scratch-check.mjs` um einen achten
|
||||
Abschnitt (`runModuleRegistryAreaChecks`) erweitert. Er setzt auf den vier
|
||||
Tabellen auf, die `runGroupsAreaChecks` bereits mit Policies WORTGLEICH aus
|
||||
den ausgelieferten Migrationen anlegt (`Group`, `GroupMembership`,
|
||||
`ModuleGrant`, `TenantModuleActivation`) und legt selbst nur hinzu: die
|
||||
Tabelle `"Module"` OHNE Zeilenschutz (die zu messende Eigenschaft selbst),
|
||||
den Eindeutigkeitsindex auf `("tenantId","moduleId")` für
|
||||
`"TenantModuleActivation"` (wortgleich aus `20260619103242_add_module_registry`
|
||||
geschnitten), zwei Direkt-Freigabezeilen und die Mitgliedschaft (group-b,
|
||||
user-a), die `runGroupsAreaChecks` unter gebundenem Kontext bewusst nicht
|
||||
anlegen konnte. Die Zeile `grant-foreign-group` aus dem Abschnitt `groups`
|
||||
wird wiederverwendet. Tatsächlich beobachtete Ausgabe dieses Laufs
|
||||
(2026-09-10, gegen `tessera-ctl-db-1`, Adresse `172.19.0.2`):
|
||||
|
||||
```
|
||||
modulegrant-ungebunden-null-zeilen: bestanden — ungebundener SELECT auf "ModuleGrant" liefert 0 Zeile(n), tatsaechlich vorhanden sind 5
|
||||
tenantmoduleactivation-ungebunden-null-zeilen: bestanden — ungebundener SELECT auf "TenantModuleActivation" liefert 0 Zeile(n), tatsaechlich vorhanden sind 3
|
||||
admin-kurzschluss-gebunden-liefert-nur-eigene-aktivierungen: bestanden — forTenant(TENANT-A) liefert 1 aktive Aktivierung(en): ["TENANT-A"]
|
||||
direktfreigabe-gebunden-nur-eigene-zeile: bestanden — forTenant(TENANT-A) liefert fuer die Direkt-Freigabe-Abfrage (userId=user-a) 1 Zeile(n): ["grant-direct-a"]
|
||||
gruppenpfad-gebunden-folgt-der-gruppenregel: bestanden — forTenant(TENANT-A) liefert ueber den Drei-Tabellen-Weg (Freigabe ueber Gruppe ueber Mitgliedschaft) fuer user-a 1 Zeile(n): ["grant-a"]
|
||||
gruppenpfad-gebunden-schliesst-die-fremde-gruppe-aus: bestanden — forTenant(TENANT-A) liefert 'grant-foreign-group' ueber denselben Drei-Tabellen-Weg NICHT (Ergebnis: ["grant-a"]), obwohl die Regel auf "ModuleGrant" diese Zeile nachweislich durchlaesst (T-JTS-03) und die Mitgliedschaft (group-b, user-a) vorhanden ist — diese Verteidigung greift erst nach dem Scharfschalten
|
||||
gruppenpfad-ueber-die-wartungsrolle-liefert-die-fremde-gruppe-mit: bestanden — dieselbe Abfrage ueber die Verwaltungsrolle (BYPASSRLS) liefert ["grant-a","grant-foreign-group"] — der Ausschluss aus Pruefung 6 kommt damit nachweislich von der Bindung, nicht vom Aufbau
|
||||
module-tabelle-traegt-keinen-zeilenschutz: bestanden — ungebundenes SELECT auf "Module" liefert 2 Zeile(n): ["mod-1","mod-2"]; pg_class.relrowsecurity fuer "Module" = false
|
||||
katalog-bindung-aendert-heute-nichts-an-der-ergebnismenge: bestanden — forTenant(TENANT-A) liefert ["mod-1","mod-2"], ungebunden liefert ["mod-1","mod-2"] — identisch, weil "Module" keine Regel traegt (Befund E: die Nichtbindung des Katalogs ist heute keine Rettung vor Unsichtbarkeit, sondern eine Frage der Wahrhaftigkeit der Aufzeichnung; sie wird erst zur Rettung, WENN Etappe 3 dieser Tabelle eine Regel gibt)
|
||||
gebundener-join-auf-den-katalog-liefert-den-modulnamen: bestanden — forTenant(TENANT-A) liefert fuer den Verbund aus Aktivierung und Katalog: [{"moduleId":"mod-1","name":"Modul Eins"}]
|
||||
aktivierung-gebundenes-einfuegen-fremder-mandant-abgelehnt: bestanden — gebundenes INSERT unter TENANT-A mit tenantId=TENANT-B abgewiesen mit SQLSTATE 42501 (ERROR: new row violates row-level security policy for table "TenantModuleActivation")
|
||||
aktivierung-eindeutigkeit-traegt-den-mandanten-keine-unsichtbare-kollision: bestanden — gebundenes INSERT von (TENANT-A, mod-2) ist GELUNGEN, obwohl (TENANT-B, mod-2) bereits existiert und unter TENANT-A unsichtbar ist — der Eindeutigkeitsindex fuehrt mit der Mandantenkennung, genau die Entlastung, die die Bereiche `tenders` und `user` NICHT hatten (dort: unsichtbare Zeile, falsches "frei", harter Eindeutigkeitsfehler)
|
||||
freigabe-eindeutigkeitsindizes-fuehren-mit-der-mandantenkennung: bestanden — aus 20260804130130_add_groups_and_module_grants extrahiert: beide partiellen Eindeutigkeitsindizes auf "ModuleGrant" ("tenantId","moduleId","groupId") und ("tenantId","moduleId","userId") fuehren mit der Mandantenkennung, dieselbe Entlastung wie Pruefung 12, hier fuer die Freigabetabelle
|
||||
Alle 66 Pruefungen bestanden.
|
||||
```
|
||||
|
||||
Die Belegzeile, die diesen Abschnitt trägt, ist
|
||||
`modulegrant-ungebunden-null-zeilen`: der IDENTISCHE `SELECT "tenantId" FROM
|
||||
"ModuleGrant"` ohne vorheriges `set_config` liefert **0 Zeilen**, nicht etwa
|
||||
die 5 tatsächlich vorhandenen — an der echten, ausgelieferten Policy
|
||||
gemessen. `tenantmoduleactivation-ungebunden-null-zeilen` misst dieselbe
|
||||
Unsichtbarkeit für die Tabelle, die der Rollen-Kurzschluss für
|
||||
ADMIN/SUPER_ADMIN als EINZIGE liest: auch hier fällt der
|
||||
Verwaltungszugriff nach dem Scharfschalten aus.
|
||||
|
||||
**TEIL 2, Beleg statt Behauptung für Befund B** — keine Transaktion in
|
||||
diesem Bereich:
|
||||
|
||||
```
|
||||
$ grep -rn '\$transaction(' apps/api/src/module-registry --include=*.ts | grep -v spec
|
||||
$ echo $?
|
||||
1
|
||||
```
|
||||
|
||||
Null Treffer, Rückgabewert 1. Der im Kopf von `prisma-tenant.extension.ts`
|
||||
verlangte erneute Test ist damit für diesen Bereich beantwortet: kein neuer
|
||||
Transaktionsfall, `withTenantTransaction()` wird hier nicht gebraucht und in
|
||||
Aufgabe 2/3 nicht eingeführt.
|
||||
|
||||
**TEIL 3, Beleg statt Behauptung für Befund G** — die Aufrufermessung für
|
||||
`isModuleActive` und `findActiveForTenant`:
|
||||
|
||||
```
|
||||
$ grep -rn "isModuleActive" apps/api/src apps/web/src packages
|
||||
apps/api/src/module-registry/module-registry.service.ts:133: async isModuleActive(tenantId: string, moduleSlug: string): Promise<boolean> {
|
||||
|
||||
$ grep -rn "findActiveForTenant" apps/api/src apps/web/src packages
|
||||
apps/api/src/module-registry/module-registry.service.ts:35: async findActiveForTenant(tenantId: string) {
|
||||
apps/api/src/module-registry/module-registry.controller.ts:51: * uses, not just tenant-wide activation. findActiveForTenant on
|
||||
```
|
||||
|
||||
`isModuleActive` hat genau EINEN Treffer, die Definition selbst — ihr
|
||||
Kopfkommentar behauptet "Used by ModuleGuard to gate access to
|
||||
module-specific endpoints"; der Wächter ruft sie nachweislich nie auf
|
||||
(`module.guard.ts` hält keinen eigenen Datenbankzugriff, siehe Befund D).
|
||||
`findActiveForTenant` hat zwei Treffer, die Definition und eine
|
||||
Prosa-Erwähnung im Kopfkommentar des Controllers ("stays unchanged for Plan
|
||||
15-03's marketplace catalog") — auch sie hat keinen echten Aufrufer, der
|
||||
Marktplatz-Katalog wird nachweislich von `getCatalogFlags` bedient. Beide
|
||||
Kommentare werden in Aufgabe 3 richtiggestellt, mit Bezug auf diese Messung.
|
||||
|
||||
### (m2) Signaltabelle je umgestelltem Pfad
|
||||
|
||||
| Pfad | Verhalten bei zu wenig Ergebnis | Konkretes Signal, Ort |
|
||||
|---|---|---|
|
||||
| `ModuleAccessService.getAccessibleModuleIds`, Rollen-Kurzschluss (ADMIN/SUPER_ADMIN) | Der gebundene Aktivierungs-Lesezugriff liefert 0 Zeilen statt der mandantenweit aktiven Module | Sidebar und Marktplatz zeigen für JEDEN Administrator des Mandanten keine Module mehr; jede Modulroute antwortet mit 403 |
|
||||
| `ModuleAccessService.getAccessibleModuleIds`, Direktweg (USER) | Der gebundene Freigabe-Lesezugriff über `userId` liefert 0 Zeilen statt der eigenen Direkt-Freigaben | Der Benutzer verliert genau die Module, die ihm direkt zugewiesen waren — ununterscheidbar von einem echten Entzug |
|
||||
| `ModuleAccessService.getAccessibleModuleIds`, Gruppenweg (USER) | Der gebundene, verschachtelte Freigabe-Lesezugriff über die Gruppenmitgliedschaft liefert 0 Zeilen statt der Gruppen-Freigaben | Der Benutzer verliert alle über Gruppen geerbten Module, während seine Direkt-Freigaben unberührt bleiben — ein teilweiser, schwer zu erklärender Verlust |
|
||||
| `ModuleAccessService.getAccessibleModuleIds`, Schnittmengenabfrage | Die gebundene Aktivierungsabfrage über `moduleId: { in: grantedIds }` liefert 0 Zeilen, obwohl Freigaben vorliegen | Ein Benutzer mit vorhandenen Freigaben sieht trotzdem kein Modul — von der leeren Vorgabemenge (kein Freigabe) nicht zu unterscheiden |
|
||||
| `ModuleAccessService.findAccessibleModules` | Der Rückgabepunkt bei leerer `accessibleIds`-Menge liefert `[]`, ohne den Katalog überhaupt anzufragen | `GET /modules/active` liefert eine leere Liste; die Sidebar ist leer |
|
||||
| `ModuleAccessService.getCatalogFlags` | Der gebundene Aktivierungs-Lesezugriff liefert 0 Zeilen statt der mandantenweit aktiven Module | Der Marktplatz zeigt für JEDES Modul `isActiveForTenant: false` UND `hasAccess: false` — eine ANDERE Unwahrheit als der Sperrhinweis: "nicht aktiviert" statt "nicht freigegeben" |
|
||||
| `ModuleRegistryService.findActiveForTenant` (heute ohne Aufrufer) | Der gebundene Aktivierungs-Lesezugriff liefert 0 Zeilen | Betrifft heute keinen erreichbaren Pfad — die Falle liegt in einer KÜNFTIGEN Verdrahtung, siehe TEIL 3 |
|
||||
| `ModuleRegistryService.activateForTenant` | Der gebundene Schreibzugriff schlägt fehl bzw. die Existenzprüfung des Katalogs (ungebunden) liefert `null` | `POST /modules/:id/activate` liefert `404 Module with id '...' not found`, obwohl das Modul existiert |
|
||||
| `ModuleRegistryService.deactivateForTenant` | Der gebundene Lesezugriff auf die Aktivierung liefert `null` statt der vorhandenen Zeile | `POST /modules/:id/deactivate` liefert `404 Module '...' is not activated for this tenant` — LAUT, siehe (m3) |
|
||||
| `ModuleRegistryService.isModuleActive` (heute ohne Aufrufer) | Der gebundene Aktivierungs-Lesezugriff liefert `null`, die Methode gibt `false` zurück | Betrifft heute keinen erreichbaren Pfad — die stille Falle für eine KÜNFTIGE Verdrahtung, siehe (m3) |
|
||||
| `ModuleRegistryService.findAll`/`findBySlug`/`seedModule` (bewusst UNGEBUNDEN, Modulkatalog) | Betrifft nicht diese Pfade selbst — sie binden nicht und liefern deshalb weiterhin korrekt. Das Risiko liegt in einer KÜNFTIGEN Bindung (Etappe 3, sobald `Module` eine Regel bekommt) | Würde man sie binden: der gesamte Modulkatalog verschwände für JEDEN Mandanten — hier ausdrücklich als Grenze festgehalten, nicht als heute beobachtbares Verhalten |
|
||||
| `ModuleAccessService`, Katalogzugriffe in `findAccessibleModules`/`getCatalogFlags` (bewusst UNGEBUNDEN) | Dieselbe Grenze wie oben, hier für die beiden Katalog-Lesezugriffe des Nachbardienstes | Dieselbe Folge: eine künftige Bindung würde den Katalog mandantenweit unsichtbar machen |
|
||||
|
||||
### (m3) Welcher Code Leere als Abwesenheit deutet
|
||||
|
||||
Nach Wirkung sortiert:
|
||||
|
||||
1. **`ModuleAccessService.getAccessibleModuleIds`, `grantedIds.length === 0`
|
||||
→ `return new Set()`** — der Rückgabepunkt bei leerer Freigabemenge. Der
|
||||
Vorgabezustand ist geschlossen (D-04/T-EXD-04); eine zu leer gebliebene
|
||||
Freigabeabfrage sieht identisch aus wie ein Benutzer ohne jede Freigabe.
|
||||
2. **`ModuleAccessService.getAccessibleModuleIds`, Rollen-Kurzschluss** —
|
||||
`if (role === 'ADMIN' || role === 'SUPER_ADMIN')` liest ausschließlich
|
||||
`tenantModuleActivation`; eine leere Aktivierungsliste liefert ein leeres
|
||||
Set, ohne die Freigabestufe überhaupt zu befragen. Betrifft damit JEDEN
|
||||
Administrator des Mandanten gleichzeitig.
|
||||
3. **`ModuleAccessService.findAccessibleModules`, `accessibleIds.size === 0`
|
||||
→ `return []`** — der Rückgabepunkt bei leerer Modulliste, bedient
|
||||
`GET /modules/active` und damit die Sidebar.
|
||||
4. **`ModuleAccessService.getCatalogFlags`** — eine leere Aktivierungsliste
|
||||
lässt die zurückgegebene Map leer; der Controller
|
||||
(`module-registry.controller.ts`, `findCatalog`) mappt einen fehlenden
|
||||
Eintrag auf BEIDE Flags `false`. Das erzeugt eine ANDERE Unwahrheit als
|
||||
der Sperrhinweis der Freigabestufe: "nicht aktiviert" statt "nicht
|
||||
freigegeben" — der Marktplatz zeigt dem Benutzer den falschen Grund für
|
||||
die Sperre.
|
||||
5. **`ModuleGuard.canActivate`, die 403-Stelle** —
|
||||
`if (!accessibleModuleIds.has(module.id)) throw new ForbiddenException(...)`.
|
||||
Dieselbe Meldung für "wirklich keine Freigabe" und "die Aufösung hat
|
||||
nichts gefunden" — siehe die Leitfrage dieses Abschnitts unten.
|
||||
6. **`ModuleRegistryService.isModuleActive`, Vorgabewert `false`** — heute
|
||||
ohne Aufrufer (TEIL 3), aber die stille Falle für morgen: `return
|
||||
activation?.isActive === true` liefert bei `null` (leerer, gebundener
|
||||
Lesezugriff) exakt dasselbe `false` wie eine echte, mandantenweite
|
||||
Deaktivierung. Wird dieser Pfad morgen verdrahtet, ist er von Fall an
|
||||
nicht mehr vom Rest dieses Abschnitts zu unterscheiden.
|
||||
|
||||
**Gegenrichtung, damit dieser Abschnitt nicht nur aus Alarm besteht:**
|
||||
`ModuleRegistryService.deactivateForTenant` wirft bei leerer
|
||||
Aktivierungsabfrage (`if (!activation) throw new NotFoundException(...)`)
|
||||
LAUT — die Ausnahme meldet sich sofort und verständlich, statt ein stilles
|
||||
`false` zu liefern. Dieselbe laute Richtung gilt für `activateForTenant` bei
|
||||
unbekannter `moduleId`.
|
||||
|
||||
**Die Frage, die dieser Bereich vor allen anderen beantworten muss: welches
|
||||
Signal unterscheidet "wirklich keine Freigabe" von "die Abfrage hat nichts
|
||||
gefunden"?** Die Antwort lautet **keines** — schlicht, ohne Beschönigung.
|
||||
Drei Stellen sehen heute identisch aus, ob der Benutzer tatsächlich keine
|
||||
Freigabe hat oder ob eine gebundene Abfrage nach dem Scharfschalten leer
|
||||
lief: dieselbe `ForbiddenException`-Meldung im Wächter
|
||||
("Module '...' is not accessible for this user"), dieselbe leere Modulliste
|
||||
mit Status 200 (`GET /modules/active`), kein einziger Protokolleintrag. Der
|
||||
Zusatz, der diesen Bereich von allen vorherigen unterscheidet: der
|
||||
Betroffene hat eine fertige, FALSCHE Erklärung zur Hand ("mein Administrator
|
||||
hat mir das entzogen") und meldet deshalb keinen Fehler — anders als etwa
|
||||
bei `LdapConfigScheduler`, wo niemand eine plausible Alltagserklärung für
|
||||
ausbleibende Synchronisation hat.
|
||||
|
||||
Die eine Asymmetrie, die sich zu einem Signal machen LIESSE, wird hier
|
||||
benannt und an Etappe 4 übergeben, nicht gelöst: nach dem Scharfschalten ist
|
||||
ein zu kleines Ergebnis in diesem Bereich TOTAL und nicht selektiv — JEDER
|
||||
Benutzer JEDES Mandanten verliert gleichzeitig jedes Modul, während die
|
||||
Aktivierungs- und Freigabetabellen weiterhin Zeilen halten. Die
|
||||
Vorabprüfung von Etappe 4 (`rls-preflight.mjs`) kann genau das feststellen:
|
||||
aktive Aktivierungszeilen vorhanden, aber die Auflösung liefert für einen
|
||||
bekannten Administrator eine leere Menge. Eine Laufzeitwarnung an den oben
|
||||
genannten Stellen wird ERWOGEN und VERWORFEN, mit derselben Begründung wie
|
||||
bei `getAllActiveConfigs` im Bereich `ldap` und den fünf Stellen im Bereich
|
||||
`tenders`: eine leere Menge ist für einen Benutzer ohne Freigabe und auf
|
||||
einer frischen Installation der Normalzustand, eine Warnung wäre Dauerlärm
|
||||
und verlöre ihr Signal.
|
||||
|
||||
### (m4) Was dieser Durchlauf bewusst nicht löst
|
||||
|
||||
- **T-JTS-02/T-JTS-03 bleiben aufgezeichnet und ungefixt.** Gemessen in
|
||||
Aufgabe 1 (Prüfungen 6/7): die Regel auf `ModuleGrant` prüft nur die
|
||||
Mandantenkennung der Zeile selbst, nicht die referenzierte Gruppe; die
|
||||
Regel auf `GroupMembership` prüft nur die Gruppenseite. Die Bindung fügt
|
||||
auf der LESESEITE eine zweite Verteidigung hinzu (der Drei-Tabellen-Weg
|
||||
schließt die fremde Gruppe gebunden aus), aber erst nach Etappe 4 — die
|
||||
Schreibseiten-Gegenprüfung in `module-grants.service.ts`
|
||||
(`assertTargetBelongsToTenant`) bleibt deshalb der heutige Schutz und wird
|
||||
durch diesen Durchlauf NICHT ersetzt.
|
||||
- **Die Regel für den Modulkatalog gehört zu Etappe 3.** Gemessen in
|
||||
Aufgabe 1 (Prüfung 8/9, Befund E): `"Module"` trägt heute keinen
|
||||
Zeilenschutz, eine Bindung wäre heute wirkungslos, nicht katastrophal.
|
||||
Katastrophal würde sie erst, WENN Etappe 3 dieser Tabelle eine Regel gibt
|
||||
— dann verschwände der gesamte Katalog für jeden Mandanten. Diese
|
||||
Bedingung steht hier als Bedingung, nicht als heute beobachtbare Tatsache.
|
||||
- **Die offene Architekturfrage `req.tenantPrisma`** — auch dieser Bereich
|
||||
entscheidet sie nicht. Er bindet dienst-intern, wie `ldap`, `groups`,
|
||||
`tenders`, `dkv` und `user` es vormachen.
|
||||
|
||||
### (m5) Was dieser Durchlauf bewusst NICHT anfasst
|
||||
|
||||
- `module.guard.ts` — geprüft (Befund D: hält keinen eigenen
|
||||
Datenbankzugriff, seine Richtigkeit ist vollständig eine Funktion dessen,
|
||||
was `ModuleAccessService` zurückgibt) und bewusst gelassen, keine Bindung
|
||||
nötig.
|
||||
- `module-registry.controller.ts` — geprüft (hält ebenfalls keinen eigenen
|
||||
Datenbankzugriff) und bewusst gelassen.
|
||||
- Das Frontend — geprüft und bewusst gelassen, keine Datei dieses Plans.
|
||||
- Schema und Migrationen — geprüft und bewusst gelassen, keine
|
||||
Schemaänderung in dieser Etappe.
|
||||
|
||||
## Verweis
|
||||
|
||||
Die Bestandsaufnahme, welche Fundstelle den hier beschriebenen Übergang
|
||||
|
||||
Reference in New Issue
Block a user