83 lines
5.0 KiB
Markdown
83 lines
5.0 KiB
Markdown
# Phase 14: RSS, Email-Alert Ingestion & Module Rollout - Discussion Log
|
|
|
|
> **Audit trail only.** Do not use as input to planning, research, or execution agents.
|
|
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
|
|
|
|
**Date:** 2026-07-23
|
|
**Phase:** 14-rss-email-alert-ingestion-module-rollout
|
|
**Areas discussed:** Inbox-Modul-Extraktion, E-Mail-Alert-Parsing, Config-Modell + Admin-UI, i18n + Sprachumschaltung
|
|
|
|
---
|
|
|
|
## Klarstellung des Phasenziels (Ausgangspunkt der Diskussion)
|
|
|
|
Der User war zunächst verwirrt, was das DKV-Modul mit dem Ausschreibungsportal zu tun hat, und nahm an, das Ausschreibungs-Modul „solle nur Mails versenden". Kernklärung:
|
|
|
|
- **Ausgehend (Phase 12, bereits gebaut):** Tessera *versendet* Benachrichtigungs-Mails an Nutzer via SMTP.
|
|
- **Eingehend (Phase 14, Kriterium 2):** Tessera *liest* ein pro Mandant konfiguriertes Postfach aus, in das Vergabeportale ihre Alert-Mails schicken, und macht daraus Ausschreibungs-Einträge.
|
|
|
|
Der Bezug zu DKV: DKV verbindet sich technisch bereits per IMAP/Exchange mit einem Postfach und verarbeitet dessen Inhalt (PDF-Anhänge). Geteilt wird nur diese Verbindungsmechanik, nicht die Postfach-Konfiguration. Der User bestätigte das Verständnis und stellte klar: Das Ausschreibungs-Postfach ist ein **separates** Postfach, nicht das DKV-Rechnungs-Postfach.
|
|
|
|
---
|
|
|
|
## Inbox-Modul-Extraktion
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| A — Interface generalisieren, DKV mitziehen | `fetchMessages()` ergänzen, IMAP/Exchange aufbohren, DKV auf neue Methode umstellen. Sauberste Architektur, aber Regressionsrisiko im produktiven DKV/NTLM-Pfad. | |
|
|
| B — Additiv, DKV unangetastet | Provider + Interface nach `inbox/` heben, PDF-Methode unverändert lassen, zusätzliche Message-Methode einführen, DKV wechselt nur Import-Pfad. | ✓ |
|
|
|
|
**User's choice:** B (folgte Claudes Empfehlung, bestätigt durch die Klarstellung getrennter Postfächer)
|
|
**Notes:** Getrennte Postfächer bedeuten, dass ohnehin nur die Verbindungslogik geteilt wird, nicht die Config — das deckt sich exakt mit dem additiven Weg. DKV läuft produktiv, Exchange-Pfad nutzt fragiles NTLM via httpntlm → Regressionsrisiko muss null bleiben.
|
|
|
|
---
|
|
|
|
## E-Mail-Alert-Parsing
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Pro-Portal-Parser | Ein Parser je bekanntem Portal. Präzise Felder, aber wartungsintensiv und spröde. | |
|
|
| Generische Extraktion | Ein Parser für alle: Links + Betreff/erste Zeile. Robust, aber dünne Feldqualität. | ✓ |
|
|
|
|
**User's choice:** Generische Extraktion (implizit, da User keine konkreten Alert-Portale nennen kann)
|
|
**Notes:** User kennt die aktuelle Praxis nicht und kann keine konkreten Alert-Portale benennen → portalspezifische Parser wären Raterei. Fähigkeit wird generisch gebaut; jeder Mandant entscheidet durch Einrichten/Leerlassen seines Postfachs, ob und was eingespeist wird. Feldarmut wird offen dokumentiert.
|
|
|
|
---
|
|
|
|
## Config-Modell + Admin-UI
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Global (Singleton wie TenderSourcePollConfig) | Eine Config für alle Mandanten. | teilweise (nur RSS) |
|
|
| Per-Tenant (wie DkvModuleConfig) | tenantId-scoped Config mit verschlüsselten Creds. | ✓ (Mailbox) |
|
|
|
|
**User's choice:** Gemischt — Postfach pro Mandant in den Modul-Einstellungen; RSS-Feeds global. Bestehende Admin-Seite erweitern.
|
|
**Notes:** User bestätigte aktiv, dass die Mailadresse in den Modul-Einstellungen hinterlegt wird und getrennt vom DKV-Postfach ist. Damit ist das per-Tenant-Modell für die Mailbox gesetzt (Vorlage DkvModuleConfig), Credentials via CalendarCryptoService verschlüsselt. Offene Detailfrage (wer genau konfiguriert) via bestehende Rollen ADMIN/SUPER_ADMIN aufgelöst.
|
|
|
|
---
|
|
|
|
## i18n + Sprachumschaltung
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Eng — nur übersetzte Strings | tender-radar-Strings in DE/EN-Keys überführen; Sprachwahl über bestehenden Mechanismus. | ✓ |
|
|
| Weit — plus Language-Switcher | Zusätzlich sichtbarer Umschalter (app-weite Infrastruktur). | |
|
|
|
|
**User's choice:** „Übersetzte Strings reichen, kein Umschalter nötig"
|
|
**Notes:** Es existiert bisher kein Language-Switcher/Locale-Routing in der App. Ein app-weiter Umschalter wäre eigene Infrastruktur → als Deferred Idea vermerkt.
|
|
|
|
---
|
|
|
|
## Claude's Discretion
|
|
|
|
- RSS-Parsing-Bibliothek + Feld-Mapping der RSS-Items (generische Bag, analog Scraper-Adapter).
|
|
- Genaue Struktur des `inbox/`-Modul-Interfaces und der zusätzlichen Message-Methode.
|
|
- Scheduler-Anbindung neuer Quellen über bestehendes SourceRegistry/pollDueSources-Muster.
|
|
- EN-Übersetzungen (Vergabe-Fachbegriffe konsistent).
|
|
|
|
## Deferred Ideas
|
|
|
|
- App-weiter Sprachumschalter (eigene Plattform-Phase).
|
|
- Portalspezifische E-Mail-Parser (erst bei bekannten Alert-Portalen + echten Mail-Samples).
|
|
- CPV-loser Zweit-Fingerprint für Cross-Source-Dedup dünner Quellen (Option A aus Phase-13-Entscheidung; erst bei Live-Aktivierung einer zweiten Quelle).
|