mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

### docs: aktualisiere ADR 0028 für E-Mail-basiertes Routing

Browse Source 
- Ersetze Catch-All-Ansatz durch Betreff-basiertes Routing.
- Reduziere Infrastruktur-Aufwände durch generische Zieladresse.
This commit is contained in:
Stefan Mogeritsch 2026-04-22 15:18:30 +02:00
parent e65384768f
commit 5baa971b46
1 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/01_Architecture/adr/0028-plan-b-email-based-online-nennung.md
View File

@ -14,7 +14,7 @@ Wir setzen das Prinzip der **Graceful Degradation** an und wechseln für das Onl
1. **Entkopplung:** Die Web-App wird vorerst nicht dynamisch aus der Desktop-App/ZNS-Datenstruktur generiert.
2. **Statische Frontend-Formulare:** Wir erstellen einfache, statische (oder semi-statische) Nenn-Formulare im Web (WasmJs) mit grundlegender clientseitiger Validierung (Pflichtfelder).
3. **E-Mail als Integrationsschicht:** Das Backend dient lediglich als "Form-to-Email-Gateway". Wenn ein Teilnehmer das Formular absendet (`POST` Request mit JSON-Payload), generiert das Backend eine strukturierte E-Mail.
4. **Catch-All Routing statt Plus-Addressing:** Aufgrund der Limitationen des Hosters nutzen wir kein Plus-Addressing. Stattdessen wird eine Subdomain (`*.turniere.mo-code.at`) mit einem Catch-All-Postfach eingerichtet. Die Web-App sendet als Empfängeradresse das Format `t-<turniernummer>@turniere.mo-code.at` (z.B. `t-26128@turniere.mo-code.at`).
4. **Betreff-basiertes Routing statt Catch-All/Plus-Addressing:** Um jegliche Infrastruktur-Änderungen beim Hoster zu vermeiden, senden wir alle Nennungen an die generische Adresse `online-nennen@mo-code.at`. Die Trennung pro Turnier erfolgt zwingend über den **Betreff der E-Mail** (z.B. `[NENNUNG] Turnier-ID: 26128`). Im Posteingang können dann einfache Filter/Regeln eingerichtet werden.
## Konsequenzen
@ -22,16 +22,14 @@ Wir setzen das Prinzip der **Graceful Degradation** an und wechseln für das Onl
* **Time-to-Market:** Die Kernanforderung (Nennungen empfangen) kann extrem schnell umgesetzt und deployt werden.
* **Stabilität:** Das System ist hochgradig ausfallsicher. Es gibt keine komplexe DB-Synchronisation, die im Live-Betrieb abbrechen könnte.
* **Kein Blocker für Desktop-App:** Das Team kann ungestört weiter an der komplexen Desktop-ZNS-Integration arbeiten, während das Nenn-Problem für die User gelöst ist.
* **Klar definierter Mail-Filter:** Durch das Catch-All können Nennungen im Postfach sauber nach der Empfängeradresse (`To: t-26128@...`) den Turnieren zugeordnet werden.
* **Keine Infrastruktur-Aufwände:** Weder Catch-All noch Alias-Verwaltung beim Hoster nötig. Ein einziges Standard-Postfach reicht.
### Negativ
* **Manueller Aufwand im Backoffice:** Nennungen kommen vorerst als E-Mails (Text/HTML) an und müssen (bis zu einer späteren Automatisierung) manuell oder per Skript aus dem Postfach ins eigentliche System übertragen werden.
* **Kein automatisiertes Setup:** Formulare müssen bei Bedarf per Hand im Frontend-Code oder einer einfachen Konfigurationsdatei angepasst werden.
* **Infrastruktur-Abhängigkeit:** Erfordert einmalige Konfiguration der Subdomain und des Catch-Alls beim Hoster.
## Nächste Schritte
1. `enableWasm=true` in `gradle.properties` aktivieren (erledigt).
2. Einrichtung der Subdomain und des Catch-All-Postfachs bei World4You klären.
3. Web-App (Frontend) mit einem minimalen "Hallo Du!"-Formular implementieren.
4. Backend-Endpoint (`POST` to Mail) implementieren und SMTP anbinden.
5. End-to-End-Test auf dem Staging/Prod-Server (Gitea Pipeline).
2. Web-App (Frontend) mit einem minimalen "Hallo Du!"-Formular implementieren, das die Turnier-ID als Parameter hält.
3. Backend-Endpoint (`POST` to Mail) implementieren und SMTP anbinden. Die Turnier-ID muss zwingend in den Mail-Betreff geschrieben werden.
4. End-to-End-Test auf dem Staging/Prod-Server (Gitea Pipeline).