Nutzer-Tenant-Kontext in Modul-Rueckkanaelen (Archive/AI/Workflow). Baut auf dem 3-Wege-Merge von INT-08+INT-09+INT-10 auf (alle noch offene PRs #294/295/296, konfliktfrei gemergt) - dieser PR enthaelt daher deren Commits mit, bis diese drei mergen.
Echter Bug gefunden und gefixt: retentionclient.CheckLegalHold sendete einen am Client fix gesetzten Tenant statt des Tenants der tatsaechlich geprueften Nachricht - bei trash.Store.PurgeExpired mit mehreren aktiven Tenants in einem Lauf waere der falsche Tenant-Kontext an Archive gegangen. Tenant-Slug jetzt als Pflichtparameter durchgereicht bis PurgeExpired, neue ErrTenantRejected-Unterscheidung im Audit-Log.
AI/Workflow-Rueckkanaele (INT-09/10) hatten Tenant-Kontext bereits korrekt pro Aufruf, serverseitig bereits unabhaengig vom Service-Token validiert - keine Aenderung dort noetig, nur per Test bestaetigt.
AC1-3 und alle 3 Pruefungen real getestet (echte Postgres, echte zweite moduladapter-api-Instanz fuer Tenant-Isolationstest). Referenzmuster DMS INT-16 genutzt.
Nutzer-Tenant-Kontext in Modul-Rueckkanaelen (Archive/AI/Workflow). Baut auf dem 3-Wege-Merge von INT-08+INT-09+INT-10 auf (alle noch offene PRs #294/295/296, konfliktfrei gemergt) - dieser PR enthaelt daher deren Commits mit, bis diese drei mergen.
Echter Bug gefunden und gefixt: retentionclient.CheckLegalHold sendete einen am Client fix gesetzten Tenant statt des Tenants der tatsaechlich geprueften Nachricht - bei trash.Store.PurgeExpired mit mehreren aktiven Tenants in einem Lauf waere der falsche Tenant-Kontext an Archive gegangen. Tenant-Slug jetzt als Pflichtparameter durchgereicht bis PurgeExpired, neue ErrTenantRejected-Unterscheidung im Audit-Log.
AI/Workflow-Rueckkanaele (INT-09/10) hatten Tenant-Kontext bereits korrekt pro Aufruf, serverseitig bereits unabhaengig vom Service-Token validiert - keine Aenderung dort noetig, nur per Test bestaetigt.
AC1-3 und alle 3 Pruefungen real getestet (echte Postgres, echte zweite moduladapter-api-Instanz fuer Tenant-Isolationstest). Referenzmuster DMS INT-16 genutzt.
Siehe mail/docs/INT-11-PRUEFPROTOKOLL.md.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
patrick
added 13 commits 2026-10-16 09:18:23 +02:00
Mail-Objekttypen message/thread samt Ausloeser-Ereignissen (mail.received,
mail.delivery_failed, mail.deadline_reached) ueber den ENG-02-Adapter bei
Workflow registrierbar (RegisterAll). Ereignis-Publikation laeuft ueber
eine eigene Postgres-Jobqueue (mail_workflow_events, FOR UPDATE SKIP
LOCKED) analog zu internal/webhook (Core) und mail/internal/indexworker:
Publisher.Publish* reiht nur ein (kein HTTP-Aufruf im Anfragepfad),
Dispatcher stellt im Hintergrund zu und macht Fehlschlaege per
last_error/Retry-Backoff sichtbar statt sie zu verwerfen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
INT-12 (DMS-Variante dieser Integration) ist auf main noch nicht gemerged,
nur auf dem eigenen Feature-Branch vorhanden. Ohne den HTTP-Endpunkt bei AI
gibt es fuer den Mail-seitigen Client aus INT-09 kein Ziel. Unveraendert aus
dem INT-12-Branch uebernommen (Service-Token-Pflicht, Tenant-Verifikation
gegen Core TEN-01/GOV-07 ueber tenantregistryclient, Route nur verdrahtet
bei konfigurierter Core-Basis-URL).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neues Paket mail/internal/moduletypeclient: schlanker HTTP-Client gegen
ai/internal/moduletypeapi (GOV-01), analog zu dms/internal/moduletypeclient
aus INT-12, mit mail-/thread-spezifischen KI-relevanten Feldern (Betreff,
Text, Anhangstext) statt DMS-Dokumentfeldern.
SetupAIObjectTypeRegistration() registriert beim (kuenftigen) Mail-Start die
Objekttypen 'mail' und 'thread' bei AI. Exportiert statt main-interner
Helfer wie bei dms/cmd/app, da mail noch keinen eigenen cmd/mail-app-
Einstiegspunkt besitzt (dokumentierte Luecke seit INT-18) - bereit fuer den
Aufruf durch einen kuenftigen Einstiegspunkt.
AK2 (optional ohne AI-Modul) und AK3 (Registrierungsfehler blockieren nie
den Mail-Betrieb) ueber Unit-Tests abgedeckt. AK1 (Registrierung erscheint
bei AI) zusaetzlich real nachgewiesen: echter ai-app-Prozess, echte
Postgres-Testdatenbank, legitimer Core-TEN-01-Stub, direkte SQL-Verifikation
(TestEndToEnd_RealAIApp_RegistersMailAndThreadObjectTypes).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die Abweichung von der Ticket-Annahme (INT-12/GOV-01-HTTP-
Endpunkt war auf main nicht gemergt, nur auf eigenem Branch), die
getroffenen Scope-Entscheidungen (kein neuer cmd/mail-app, deklarative
Thread-Registrierung ohne eigenes Thread-Datenmodell) und die realen
Pruefergebnisse je Akzeptanzkriterium.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mail registriert mail_message/mail_attachment inkl. Aufbewahrungsklasse
bei Archive RET-05 (retentionregister.RegisterAll); vor jeder Papierkorb-
Aktion/Endloeschung fragt trash.Store ueber den bereits vorhandenen
legalhold-Checker RET-13 ab. Ablehnung (Sperre ODER nicht erreichbares
Archive) wird neu im Mail-Audit-Log vermerkt (audittrail), Loeschung
bleibt in beiden Faellen aus (fail closed). Vertragstest gegen den
echten archive/cmd/moduleadapter-api-Dienst (scripts/legalhold-contract-
test-mail.sh) bestaetigt reale Registrierung und Sperrabfrage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Je Akzeptanzkriterium ein automatisierter Test, real gegen Postgres
(TEST_TENANT_DSN) UND gegen eine echte, als Subprozess gestartete
workflow-app (workflow/cmd/workflow-app) -- kein HTTP-Fake, da Mail und
Workflow als getrennte Go-Module ausschliesslich ueber den echten
ENG-02-Adapter gekoppelt sind:
- RegisterAll traegt message/thread samt Triggern tatsaechlich in
module_registrations/module_registration_versions der laufenden
Workflow-Instanz ein, auch bei wiederholtem Aufruf (Dienst-Neustart).
- PublishMailReceived + Dispatcher.RunOnce liefern mail.received
nachweisbar in module_events der echten Instanz aus.
- Ein nicht erreichbarer Workflow-Endpunkt blockiert Enqueue nicht und
hinterlaesst last_error/Status pending statt das Ereignis zu
verwerfen.
Dabei Fehler im ENG-02-Adapter gefunden und umgangen (nicht am Adapter
selbst behoben, anderes Modul/Board): PublishEvent setzt einen leeren
dedupe_key per NULLIF auf NULL, die Spalte ist aber NOT NULL -- jede
Zustellung ohne Dedup-Schluessel schlug serverseitig fehl. Mail liefert
deshalb immer einen abgeleiteten dedupe_key (mail:{object_type}:{trigger}:{object_id})
statt sich auf einen leeren Schluessel zu verlassen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zielwerte und Ergebnisse aller drei Pflichtpruefungen dokumentiert,
inklusive des gefundenen dedupe_key-NOT-NULL-Fehlers im ENG-02-Adapter
(dort nicht behoben, nur in Mail umgangen) und der bewusst offenen
Verdrahtung in einen konkreten SMTP-/Hotfolder-Zustellpfad.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
retentionclient.CheckLegalHold erhaelt den Tenant-Kontext der konkret
geprueften Nachricht als Pflichtparameter statt ihn aus dem fest am
Client verankerten c.Tenant zu nehmen - trash.Store verwaltet mehrere
Mandanten in einem Schema, PurgeExpired haette sonst Kandidaten
verschiedener Mandanten mit demselben (falschen) Tenant-Kontext
abgefragt. legalhold.Verify/Checker reichen tenantSlug entsprechend
durch und unterscheiden eine vom Archive-Modul abgelehnte
Tenant-Fehlpassung (ErrTenantRejected) von einem gewoehnlichen
Transportfehler. trash.PurgeExpired reicht nun den tenant_slug jedes
Kandidaten durch und vermerkt eine Ablehnung wegen Tenant-Mismatch im
Audit-Log mit eigenem reason=tenant_mismatch.
AI (moduletypeclient.Register) und Workflow (workflowevent/
moduleadapter.PublishEvent) tragen den Tenant-Kontext bereits als
Pflichtparameter bzw. validieren ihn bereits serverseitig unabhaengig
vom Service-Token - keine Aenderung dort noetig.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Unit-Tests (retentionclient, legalhold) belegen: CheckLegalHold sendet
den per-call uebergebenen Tenant statt c.Tenant, ein leerer Tenant
loest keinen HTTP-Aufruf aus, ein 403 wird als ErrForbidden/
ErrTenantRejected unterscheidbar. Neue Integrationstests (echtes
Postgres) in mail/internal/trash/tenant_isolation_test.go decken
Pruefung 1-3 des Tickets ab: korrekter Tenant liefert erwartete Daten,
manipulierter Tenant wird abgelehnt und im Audit-Log als
tenant_mismatch vermerkt, zwei Mandanten bleiben in einem
PurgeExpired-Lauf isoliert. Bestehende Tests (allow/deny-Helfer,
TestArchiveContract_*) auf die neue Signatur angepasst.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
scripts/legalhold-contract-test-mail.sh startet zusaetzlich eine
zweite, echte moduleadapter-api-Instanz mit eigener Datenbank fuer
einen zweiten Mandanten (globex-contract-mail) und prueft die
Isolation gegen die Archive-Instanz von acme-contract-mail in beiden
Richtungen - Pruefung 3 des Tickets damit auch gegen echte,
getrennte Zielmodul-Instanzen abgedeckt, nicht nur gegen einen
Stub. mail/docs/INT-11-PRUEFPROTOKOLL.md dokumentiert den
Drei-Wege-Merge, die gefundene Luecke, die Umsetzung je
Akzeptanzkriterium und alle durchgefuehrten Pruefungen mit Ergebnis.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Nutzer-Tenant-Kontext in Modul-Rueckkanaelen (Archive/AI/Workflow). Baut auf dem 3-Wege-Merge von INT-08+INT-09+INT-10 auf (alle noch offene PRs #294/295/296, konfliktfrei gemergt) - dieser PR enthaelt daher deren Commits mit, bis diese drei mergen.
Echter Bug gefunden und gefixt: retentionclient.CheckLegalHold sendete einen am Client fix gesetzten Tenant statt des Tenants der tatsaechlich geprueften Nachricht - bei trash.Store.PurgeExpired mit mehreren aktiven Tenants in einem Lauf waere der falsche Tenant-Kontext an Archive gegangen. Tenant-Slug jetzt als Pflichtparameter durchgereicht bis PurgeExpired, neue ErrTenantRejected-Unterscheidung im Audit-Log.
AI/Workflow-Rueckkanaele (INT-09/10) hatten Tenant-Kontext bereits korrekt pro Aufruf, serverseitig bereits unabhaengig vom Service-Token validiert - keine Aenderung dort noetig, nur per Test bestaetigt.
AC1-3 und alle 3 Pruefungen real getestet (echte Postgres, echte zweite moduladapter-api-Instanz fuer Tenant-Isolationstest). Referenzmuster DMS INT-16 genutzt.
Siehe mail/docs/INT-11-PRUEFPROTOKOLL.md.
🤖 Generated with Claude Code
Je Akzeptanzkriterium ein automatisierter Test, real gegen Postgres (TEST_TENANT_DSN) UND gegen eine echte, als Subprozess gestartete workflow-app (workflow/cmd/workflow-app) -- kein HTTP-Fake, da Mail und Workflow als getrennte Go-Module ausschliesslich ueber den echten ENG-02-Adapter gekoppelt sind: - RegisterAll traegt message/thread samt Triggern tatsaechlich in module_registrations/module_registration_versions der laufenden Workflow-Instanz ein, auch bei wiederholtem Aufruf (Dienst-Neustart). - PublishMailReceived + Dispatcher.RunOnce liefern mail.received nachweisbar in module_events der echten Instanz aus. - Ein nicht erreichbarer Workflow-Endpunkt blockiert Enqueue nicht und hinterlaesst last_error/Status pending statt das Ereignis zu verwerfen. Dabei Fehler im ENG-02-Adapter gefunden und umgangen (nicht am Adapter selbst behoben, anderes Modul/Board): PublishEvent setzt einen leeren dedupe_key per NULLIF auf NULL, die Spalte ist aber NOT NULL -- jede Zustellung ohne Dedup-Schluessel schlug serverseitig fehl. Mail liefert deshalb immer einen abgeleiteten dedupe_key (mail:{object_type}:{trigger}:{object_id}) statt sich auf einen leeren Schluessel zu verlassen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Inhalt bereits in main enthalten (geprueft per merge_all_prs.sh: leerer Merge-Diff). Geschlossen ohne Merge.
Pull request closed