sysops
b3c8d36b58
mailrules.Store (IMP-03) bekommt Update (bislang nur Create/List/
Delete) — gleiches Muster wie Create: Musterprüfung vor dem Schreiben,
streng auf tenant_slug+id beschränkt, ErrNotFound bei fremder/nicht
existierender ID.
Neues Paket mail/internal/mailrulesapi: vier Endpunkte (GET/POST
/api/v1/mail/rules, PUT/DELETE /api/v1/mail/rules/{id}), tenant-Query-
Parameter Pflicht, gleiche Konvention wie mailapi (INT-01).
Akzeptanzkriterium 3 ist strukturell garantiert: mailrulesapi ruft
ausschließlich mailrules.Store auf, denselben Store, den IMP-03s
Import-Pfad ohnehin verwendet — kein zweiter, paralleler Schreibpfad.
Alle drei Pflichtprüfungen mit echten Nachweisen: vollständiger
Anlegen/Priorisieren/Einsehen/Löschen-Zyklus über echte HTTP-Requests;
eine über die API angelegte Regel wird über genau den Weg gelesen und
ausgewertet, den IMP-03s Import-Pfad geht (Store.List ->
mailrules.NewEngine -> Evaluate) und liefert das korrekte
Klassifizierungsergebnis; Mandant Bs Update-Versuch mit der echten,
bekannten ID von Mandant As Regel liefert 404, Mandant As Regel bleibt
unverändert.
go build/go vet/golangci-lint clean, gesamtes Mail-Modul
regressionsfrei getestet — bestehende mailrules-Tests (IMP-03/IMP-09)
bleiben nach der Update-Erweiterung unverändert grün.
83 lines
3.5 KiB
Markdown
83 lines
3.5 KiB
Markdown
# INT-06 — E-Mail-Regel-Engine über API steuerbar: Prüfprotokoll
|
|
|
|
Datum: 2026-09-01
|
|
Host: 192.168.1.131 (Build/Test/Lint), rsync + ssh
|
|
Pakete: `mail/internal/mailrulesapi` (neu), `mail/internal/mailrules` (erweitert)
|
|
|
|
## Umsetzung
|
|
|
|
`mailrules.Store` (IMP-03) hatte bislang nur `Create`/`List`/`Delete` —
|
|
kein `Update`. Ergänzt um `Store.Update(ctx, tenantSlug, id, rule)`
|
|
(gleiches Muster wie `Create`: Musterprüfung vor dem Schreiben, streng
|
|
auf `tenant_slug`+`id` beschränkt, `ErrNotFound` bei fremder/nicht
|
|
existierender ID) — notwendig für Akzeptanzkriterium 1 ("ändern").
|
|
|
|
Neues Paket `mail/internal/mailrulesapi`: vier Endpunkte
|
|
(`GET`/`POST /api/v1/mail/rules`, `PUT`/`DELETE
|
|
/api/v1/mail/rules/{id}`), `tenant`-Query-Parameter Pflicht, gleiche
|
|
Konvention wie `mailapi` (INT-01). **Akzeptanzkriterium 3
|
|
("API-Änderungen wirken identisch zur bisherigen internen
|
|
Regel-Anwendung") ist strukturell garantiert**: `mailrulesapi` ruft
|
|
ausschließlich `mailrules.Store` auf — denselben Store, den IMP-03s
|
|
Import-Pfad ohnehin verwendet. Es gibt keinen zweiten,
|
|
parallelen Schreibpfad, der abweichen könnte.
|
|
|
|
## Pflichtprüfung 1: Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab
|
|
|
|
`TestContract_CreateUpdateDeletePrioritize`: vollständiger Zyklus über
|
|
echte HTTP-Requests — Anlegen (201), Priorität ändern (200, `Priority:
|
|
10 → 1`), Einsehen (Liste zeigt aktualisierten Wert), Löschen (204),
|
|
erneutes Einsehen (leere Liste).
|
|
|
|
Ergebnis: **BESTANDEN**.
|
|
|
|
## Pflichtprüfung 2: über API gesetzte Regel wird beim nächsten Import korrekt angewendet
|
|
|
|
`TestIntegration_RuleSetViaAPIAppliedCorrectlyByEngine`: Regel über
|
|
einen echten HTTP-`POST`-Request angelegt, danach über GENAU DEN WEG
|
|
gelesen und ausgewertet, den IMP-03s Import-Pfad geht
|
|
(`store.List` → `mailrules.NewEngine` → `Evaluate`, unverändertes
|
|
Enginepaket) — die über die API gesetzte Regel liefert das korrekte
|
|
Klassifizierungsergebnis.
|
|
|
|
Ergebnis: **BESTANDEN**.
|
|
|
|
## Pflichtprüfung 3: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten
|
|
|
|
`TestIntegration_RuleChangeIsolatedPerTenant`: Mandant A legt eine
|
|
Regel über die API an; Mandant B sieht sie nicht in seiner Liste;
|
|
Mandant Bs Update-Versuch mit der ECHTEN, bekannten ID von Mandant As
|
|
Regel liefert `404` (nicht etwa eine stillschweigend erfolgreiche
|
|
Übernahme); Mandant As Regel bleibt danach nachweislich unverändert.
|
|
|
|
Ergebnis: **BESTANDEN**.
|
|
|
|
## Akzeptanzkriterien
|
|
|
|
1. **Regeln lassen sich vollständig über die API anlegen, ändern und
|
|
löschen**: durch Pflichtprüfung 1 belegt.
|
|
2. **Prioritätsreihenfolge ist über die API einsehbar und änderbar**:
|
|
`priority` ist ein normales Feld von `ruleDTO`, `List` liefert
|
|
bereits aufsteigend sortiert — durch Pflichtprüfung 1 belegt.
|
|
3. **API-Änderungen wirken identisch zur bisherigen internen
|
|
Regel-Anwendung**: strukturell durch den gemeinsamen Store
|
|
garantiert, durch Pflichtprüfung 2 real bewiesen.
|
|
|
|
## Build/Vet/Lint/Test — Gesamtmodul
|
|
|
|
```
|
|
go build ./... → OK
|
|
go vet ./... → OK
|
|
golangci-lint run ./... → 0 issues
|
|
go test ./... -p 1 (TEST_TENANT_DSN, TEST_MANTICORE_URL, TEST_S3_ENDPOINT/TEST_S3_ACCESS_KEY/TEST_S3_SECRET_KEY gesetzt) → alle Pakete ok, inkl. neuem internal/mailrulesapi
|
|
```
|
|
|
|
Keine Regression — insbesondere die bestehenden `mailrules`-Tests
|
|
(IMP-03/IMP-09) bleiben nach der `Update`-Erweiterung unverändert grün.
|
|
|
|
## Ergebnis
|
|
|
|
INT-06 erfüllt alle Akzeptanzkriterien mit echten, ausgeführten
|
|
Nachweisen. Freigeschaltet: QA-06 (zusammen mit INT-09/INT-10, weiterhin
|
|
extern blockiert).
|