entityId-Waechter fuer die sechs both-Aktionen — 501 statt beliebigem Treffer
Die sechs `availability: 'both'`-Aktionen (archive, ignore-in-merge, blacklist,
add-to-list, assign-segment, export) lesen `req.params.id` und schreiben mit
`{_id: entityId, _customerID}`. An der Sammel-Adresse gibt es keine Kennung, und
Mongoose ENTFERNT `_id: undefined` still aus dem Filter statt zu werfen — der
Zugriff traefe damit einen BELIEBIGEN Datensatz des Mandanten, ohne Fehler und
ohne Protokollzeile.
Geschuetzt waren sie bis hierher nur durch die ABWESENHEIT der Sammel-Route: ein
Hand-Haertungs-Marker haelt den Erzeuger davon ab, sie dort erneut zu mounten.
Das war noetig, weil genau das schon EINMAL passiert ist (Commit 5bc61ad).
Abwesenheit ist keine Abwehr — die Ruempfe tragen jetzt selbst den Waechter aus
der Erzeuger-Vorlage (`actionStub.ts.tpl:64-82`) und antworten ehrlich 501.
Verhalten mit gueltiger Kennung ist unveraendert (reine Einfuegung, 6x16 Zeilen).
Proben: `sammelAdresseWaechter.test.ts` — je Aktion das PAAR aus Abweisung ohne
Kennung (KEIN Datenbank-Zugriff, KEIN Ereignis) und UMKEHRPROBE mit Kennung
(regulaerer Weg laeuft), plus zwei Negativkontrollen (leere Kennung wird ebenso
abgewiesen; der Waechter kommt beim isValid-Ausstieg nicht zum Zug). 14 Faelle.
Flip-Probe gefahren: Waechter aus actionConsumerArchive entfernt -> 2 rot, nach
byte-genauer Wiederherstellung 14/14. Volle Reihe 1878/1878.
Der Marker-Kommentar ist nachgezogen: er behauptete, die sechs seien draussen,
WEIL ihre Ruempfe die Kennung binden. Das gilt nicht mehr — sie bleiben draussen,
weil ein 501-Weg kein Nutzen ist; wer die Sammel-Form braucht, implementiert sie
mit Kennungen im Rumpf und aendert `availability` auf `many`.
Brief: crm-consumers-both-aktionen-und-sammel-rechte-fundament-fix
Session-Id: crm-consumers-both-aktionen-und-sammel-rechte-fundament-fix-TBD
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012LmDa2yAaQZtJrAss6EuZ8
add-to-list, assign-segment, export) lesen `req.params.id` und schreiben mit
`{_id: entityId, _customerID}`. An der Sammel-Adresse gibt es keine Kennung, und
Mongoose ENTFERNT `_id: undefined` still aus dem Filter statt zu werfen — der
Zugriff traefe damit einen BELIEBIGEN Datensatz des Mandanten, ohne Fehler und
ohne Protokollzeile.
Geschuetzt waren sie bis hierher nur durch die ABWESENHEIT der Sammel-Route: ein
Hand-Haertungs-Marker haelt den Erzeuger davon ab, sie dort erneut zu mounten.
Das war noetig, weil genau das schon EINMAL passiert ist (Commit 5bc61ad).
Abwesenheit ist keine Abwehr — die Ruempfe tragen jetzt selbst den Waechter aus
der Erzeuger-Vorlage (`actionStub.ts.tpl:64-82`) und antworten ehrlich 501.
Verhalten mit gueltiger Kennung ist unveraendert (reine Einfuegung, 6x16 Zeilen).
Proben: `sammelAdresseWaechter.test.ts` — je Aktion das PAAR aus Abweisung ohne
Kennung (KEIN Datenbank-Zugriff, KEIN Ereignis) und UMKEHRPROBE mit Kennung
(regulaerer Weg laeuft), plus zwei Negativkontrollen (leere Kennung wird ebenso
abgewiesen; der Waechter kommt beim isValid-Ausstieg nicht zum Zug). 14 Faelle.
Flip-Probe gefahren: Waechter aus actionConsumerArchive entfernt -> 2 rot, nach
byte-genauer Wiederherstellung 14/14. Volle Reihe 1878/1878.
Der Marker-Kommentar ist nachgezogen: er behauptete, die sechs seien draussen,
WEIL ihre Ruempfe die Kennung binden. Das gilt nicht mehr — sie bleiben draussen,
weil ein 501-Weg kein Nutzen ist; wer die Sammel-Form braucht, implementiert sie
mit Kennungen im Rumpf und aendert `availability` auf `many`.
Brief: crm-consumers-both-aktionen-und-sammel-rechte-fundament-fix
Session-Id: crm-consumers-both-aktionen-und-sammel-rechte-fundament-fix-TBD
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012LmDa2yAaQZtJrAss6EuZ8