test(tender-radar): Verbindungstest abgenommen (#16 zu), Postfach-Test zurueckgestellt
Abnahme im Browser auf alpha gegen den echten Exchange owa.ctl.de, nachdem die Container mit --force-recreate getauscht waren. Der blosse pull genuegte nicht: die neue Route fehlte im laufenden Container und war im gezogenen Image vorhanden — hart belegt statt vermutet. Alle vier Punkte bestanden: - gespeicherte Konfiguration mit LEEREM Passwortfeld meldet "Verbindung erfolgreich" — belegt zugleich den Rueckgriff auf die gespeicherten verschluesselten Zugangsdaten - absichtlich falscher Server meldet "Verbindung fehlgeschlagen: getaddrinfo ENOTFOUND owa-gibtsnicht.ctl.de" - keine Zugangsdaten im API-Protokoll (die Treffer einer Mustersuche waren Routennamen wie /auth/reset-password) - der Test schreibt nichts; die gespeicherte Konfiguration blieb unveraendert Nebenbefund mit Gewicht: das Protokoll zeigt eine echte Antwort von Exchange 2019 (ServerVersionInfo 15.2) samt aufgeloester FolderId. Der in Plan 14-03 als fragil markierte, handgeschriebene NTLM/SOAP-Weg ist damit erstmals gegen einen echten Server gemessen — bisher lag nur gemocktes httpntlm.post vor. WINDOWS #12 zurueckgestellt (waived): es gibt intern kein Postfach, in das Ausschreibungs-Alarme hereinkommen. Ein frueheres Missverstaendnis hatte eines angenommen. Nachzuholen, sobald ein solches Postfach existiert; offen ist dann allein das Einlesen einer echten Alarm-Mail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
This commit is contained in:
+8
-8
@@ -5,10 +5,10 @@ milestone_name: Plattform-Berechtigungen
|
||||
current_phase: 17
|
||||
current_phase_name: eigene-ausschreibungs-quellen-je-nutzer
|
||||
status: verified
|
||||
stopped_at: "WINDOWS #4 und #6 am 2026-09-07 geschlossen, ohne jede Aenderung am Active Directory. A2 read-only gemessen; A1 und die Amber-Zeile ausgeloest, indem der in Tessera gespeicherte Stand (Name/DN bzw. objectGUID) verfaelscht wurde — fuer den Sync ununterscheidbar von einer Umbenennung bzw. Loeschung im Verzeichnis. Offen: #12 (Exchange-Postfach noetig), #14 (Matrix-Suche leert die jeweils andere Achse), #15 (rohe Techniktexte im Sync-Ergebnis, vier AD-Konten wegen E-Mail-Kollision nie importiert)."
|
||||
last_updated: "2026-09-07T15:45:00.000Z"
|
||||
last_activity: 2026-09-07
|
||||
last_activity_desc: Quick-Task 260907-let — Verbindungstest fuer das Postfach nachgeruestet, verifiziert, Browser-Abnahme offen
|
||||
stopped_at: "WINDOWS #16 am 2026-09-09 im Browser auf alpha abgenommen und geschlossen: Verbindungstest meldet mit leerem Passwortfeld Erfolg (belegt den Rueckgriff auf gespeicherte Zugangsdaten), falscher Server meldet die echte Fehlermeldung, keine Zugangsdaten im Protokoll, gespeicherte Konfiguration unveraendert. Nebenbei erstmals belegt, dass der handgeschriebene EWS-Weg gegen den echten Exchange laeuft. WINDOWS #12 zurueckgestellt — es gibt intern kein Postfach fuer Ausschreibungs-Alarme. Offen sind nur noch die zwei am 2026-09-07 gefundenen Defekte: #14 (Matrix-Suche leert die jeweils andere Achse) und #15 (rohe Techniktexte im Sync, vier AD-Konten wegen E-Mail-Kollision nie importiert)."
|
||||
last_updated: "2026-09-09T07:20:00.000Z"
|
||||
last_activity: 2026-09-09
|
||||
last_activity_desc: Verbindungstest-Knopf live abgenommen (WINDOWS #16 zu), Postfach-Test #12 mangels Postfach zurueckgestellt
|
||||
progress:
|
||||
total_phases: 17
|
||||
completed_phases: 17
|
||||
@@ -371,7 +371,7 @@ Items acknowledged and carried forward from previous milestone close:
|
||||
|----------|------|--------|-------------|
|
||||
| ~~Live-Test AD~~ | **WINDOWS #4 am 2026-09-07 geschlossen.** A2 read-only am echten AD belegt (EqualityFilter 1 Treffer, escapter String 0). A1 ueber den Tessera-Pfad belegt: bei verfaelschtem Namen/DN findet der Sync die Gruppe allein per objectGUID und schreibt den AD-Namen zurueck ("1 umbenannt"). Nicht gemessen, weil dafuer das Verzeichnis geaendert werden muesste: dass AD den objectGUID bei Umbenennung stabil haelt — zugesicherte AD-Eigenschaft, kein Tessera-Code | erledigt | 2026-09-07 |
|
||||
| ~~Live-Test AD~~ | **WINDOWS #6 am 2026-09-07 geschlossen.** (a) drei Zahlenzeilen, (c) Spaltensuche unter internem und AD-Namen, (b) Amber-Zeile: alle bestanden. (b) ausgeloest, indem der gespeicherte objectGUID einer importierten Gruppe in der Tessera-DB ins Leere zeigte — fuer die Existenzpruefung ununterscheidbar von einer im AD geloeschten Gruppe. Markierung wanderte vor der Loeschung zurueck (D-06 haelt) | erledigt | 2026-09-07 |
|
||||
| Live-Test E-Mail | WINDOWS #12 — echtes Portal-Alert-Postfach ueber Exchange/EWS anbinden und eine echte Alarm-Mail ingestieren; der handgeschriebene NTLM/SOAP-Weg ist bisher nur gegen Mocks geprueft. Stand 2026-09-07: auf alpha ist **kein Postfach hinterlegt** (`TenderEmailConfig` leer) — der Test kann erst starten, wenn Postfachadresse, EWS-Adresse und Zugangsdaten vorliegen | offen, wartet auf Zugangsdaten | 2026-09-07 |
|
||||
| Live-Test E-Mail | **WINDOWS #12 am 2026-09-09 zurueckgestellt** (Ledger: waived). Es gibt intern derzeit **kein Postfach, in das Ausschreibungs-Alarme hereinkommen** — die Voraussetzung existiert nicht; ein frueheres Missverstaendnis hatte eines angenommen. Nachzuholen, sobald ein Alarm-Postfach eingerichtet ist. **Teilentlastung:** der handgeschriebene NTLM/EWS-Weg wurde am 2026-09-09 beim Test von #16 erstmals gegen den echten Exchange `owa.ctl.de` gemessen — Anmeldung, FindFolder und Ordneraufloesung funktionieren (echte ServerVersionInfo 15.2 im Protokoll). Offen bleibt allein das Einlesen einer echten Alarm-Mail | zurueckgestellt, Voraussetzung fehlt | 2026-09-09 |
|
||||
|
||||
**Entscheidung des Users vom 2026-09-07 zum AD-Zugriff:** An der AD-Struktur
|
||||
wird **nichts veraendert** — nicht von Claude, nicht vom User. Keine
|
||||
@@ -401,7 +401,7 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
|
||||
|
||||
## Session Continuity
|
||||
|
||||
Last session: 2026-09-07T15:45:00.000Z
|
||||
Stopped at: Quick-Task 260907-let abgeschlossen — Verbindungstest fuer das Postfach im Ausschreibungs-Radar nachgeruestet und verifiziert (5/5 Muss-Kriterien, alle Testlaeufe gruen). Offen bleibt die Browser-Abnahme gegen ein echtes Postfach, die einen Neubau durch den User braucht; WINDOWS #16 bleibt bis dahin offen. Weitere offene Punkte: #12 (Exchange-Postfach), #14 (Matrix-Suche), #15 (rohe Techniktexte im Sync).
|
||||
Last session: 2026-09-09T07:20:00.000Z
|
||||
Stopped at: Alle Pruefpunkte abgearbeitet. Offen sind nur noch zwei Reparaturen: WINDOWS #14 (Suche in der Freigaben-Matrix filtert beide Achsen und leert dadurch die jeweils andere) und #15 (Sync reicht rohe Prisma- und englische Techniktexte durch; vier AD-Konten aus OU=CTL_PWS_Gruppen werden wegen geteilter E-Mail-Adresse nie importiert). Zurueckgestellt: #12 (kein Alarm-Postfach vorhanden) und Abnahmeplan 02-05 (Mandantentrennung, intern zweitrangig).
|
||||
Resume file: None
|
||||
Last activity: 2026-09-07 - Verbindungstest fuer das Postfach nachgeruestet (Quick 260907-let)
|
||||
Last activity: 2026-09-09 - WINDOWS #16 abgenommen und geschlossen, #12 zurueckgestellt
|
||||
|
||||
+11
-11
@@ -1,10 +1,10 @@
|
||||
---
|
||||
schema_version: 1
|
||||
open_count: 4
|
||||
waived_count: 0
|
||||
fixed_count: 12
|
||||
open_count: 2
|
||||
waived_count: 1
|
||||
fixed_count: 13
|
||||
total_count: 16
|
||||
last_updated: 2026-09-07T13:22:33.916Z
|
||||
last_updated: 2026-09-09T05:20:34.736Z
|
||||
---
|
||||
|
||||
# Broken Windows Ledger
|
||||
@@ -26,11 +26,11 @@ last_updated: 2026-09-07T13:22:33.916Z
|
||||
| 9 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/settings/page.tsx | | Browser-Gegenprobe Plan 17-03 Task 2: USER-Konto sieht keine Bedienelemente auf /settings (nur Hinweis+Verweis), ADMIN-Konto sieht Abrufintervall+plattformweite Feeds ohne Postfach/Benachrichtigung, Zahnrad fuehrt in beiden Faellen nach Meine Quellen — kein Browser-Tool in dieser Sitzung verfuegbar | fixed | | 2026-08-12T10:02:49.291Z | 2026-09-07T07:50:56.910Z |
|
||||
| 10 | 15 | unmet-truth | apps/web/src/app/(portal)/modules/tender-radar/page.tsx | | PERM-04 greift nicht auf modul-eigenen Routen: der Zugriffs-Guard sitzt nur in modules/[category]/[moduleSlug]/page.tsx. Die vier fest verdrahteten Modulrouten (tender-radar, dkv-fleet, cert-manager, domaincheck) samt Unterseiten (z.B. tender-radar/my-sources) laufen daran vorbei und rendern fuer einen USER OHNE Modulfreigabe vollstaendig, inklusive bedienbarer Knoepfe. Im Browser gemessen am 2026-09-07 mit nutzer2 (keine Freigabe): /modules/procurement/tender-radar zeigt korrekt die 403-Seite, /modules/tender-radar und /modules/tender-radar/my-sources und /modules/dkv-fleet zeigen die volle Seite. Keine Datenpreisgabe - die API antwortet auf allen Endpunkten mit 403 - aber der Nutzer sieht Bedienelemente, die er nicht benutzen darf, und bekommt rohe englische Techniktexte statt einer verstaendlichen Meldung. Beleg: .planning/phases/17-eigene-ausschreibungs-quellen-je-nutzer/uat-2026-09-07/befund-modul-eigene-route-ohne-freigabe.png | fixed | | 2026-09-07T08:03:45.978Z | 2026-09-07T08:40:04.951Z |
|
||||
| 11 | 13 | unmet-truth | apps/api/src/tenders/tender-fingerprint.ts | | Cross-Source-Dedup kollabiert die Mehrzahl echter Duplikate nicht: tenderFingerprint() haengt [buyerName, title, cpvDivisionKey, deadlineKey, valueBucket] zu einem String und hasht ihn. Die Scraper-Adapter liefern cpvDivisions immer leer, DOE dagegen meist gefuellt - dieselbe Ausschreibung ergibt aus beiden Quellen verschiedene Fingerabdruecke, die Fingerprint-Stufe greift also gerade dort nicht, wo sie greifen soll. Steht als offener Rest in 13-VERIFICATION.md (status gaps_found, 3/4 Wahrheiten), war aber bisher nicht im Ledger und damit unsichtbar. Die frueher vermutete Ursache (Normalizer-Defaults) ist mit 9881005 geschlossen und nicht gemeint. | fixed | | 2026-09-07T08:09:04.188Z | 2026-09-07T08:42:34.794Z |
|
||||
| 12 | 14 | unrun-verify | .planning/phases/14-rss-email-alert-ingestion-module-rollout/14-03-PLAN.md | | 14-03 Task 4 (checkpoint human-verify, gate blocking): echtes Portal-Alert-Postfach ueber den Exchange/EWS-Weg anbinden und eine echte Alarm-Mail ingestieren. Zu belegen sind (a) die Mail erzeugt eine mandantenprivate Ausschreibung, (b) ein anderer Mandant sieht sie nicht, (c) der EWS-Body-Abruf liefert nicht-leeren, nicht-verstuemmelten Inhalt gegen einen echten Exchange-Server. Der handgeschriebene NTLM/SOAP-Weg ist nur gegen gemocktes httpntlm.post geprueft, nie gegen einen echten Server. Braucht ein echtes Postfach - vom User am 2026-07-24 bewusst zurueckgestellt. Stand bisher nur in 14-VERIFICATION.md (status human_needed), nicht im Ledger. | open | | 2026-09-07T08:09:04.406Z | |
|
||||
| 12 | 14 | unrun-verify | .planning/phases/14-rss-email-alert-ingestion-module-rollout/14-03-PLAN.md | | 14-03 Task 4 (checkpoint human-verify, gate blocking): echtes Portal-Alert-Postfach ueber den Exchange/EWS-Weg anbinden und eine echte Alarm-Mail ingestieren. Zu belegen sind (a) die Mail erzeugt eine mandantenprivate Ausschreibung, (b) ein anderer Mandant sieht sie nicht, (c) der EWS-Body-Abruf liefert nicht-leeren, nicht-verstuemmelten Inhalt gegen einen echten Exchange-Server. Der handgeschriebene NTLM/SOAP-Weg ist nur gegen gemocktes httpntlm.post geprueft, nie gegen einen echten Server. Braucht ein echtes Postfach - vom User am 2026-07-24 bewusst zurueckgestellt. Stand bisher nur in 14-VERIFICATION.md (status human_needed), nicht im Ledger. | waived | Zurueckgestellt auf Entscheidung des Users vom 2026-09-09: es gibt intern derzeit KEIN Postfach, in das Ausschreibungs-Alarme hereinkommen — die Voraussetzung des Pruefpunkts existiert nicht. Ein frueheres Missverstaendnis hatte ein solches Postfach angenommen. Nachzuholen, sobald ein Alarm-Postfach eingerichtet ist: dann sind (a) mandantenprivate Ausschreibung aus der Mail, (b) Unsichtbarkeit fuer andere Mandanten und (c) nicht-leerer, nicht-verstuemmelter Nachrichtentext zu belegen. Teilentlastung vom 2026-09-09: der handgeschriebene NTLM/EWS-Weg wurde beim Test von #16 erstmals gegen den echten Exchange owa.ctl.de gemessen — Anmeldung, FindFolder und Ordneraufloesung funktionieren, belegt durch die echte ServerVersionInfo-Antwort (Exchange 15.2) im API-Protokoll. Der frueher als fragil markierte Verbindungsaufbau ist damit nicht mehr ungeprueft; offen bleibt allein das Einlesen einer echten Alarm-Mail. | 2026-09-07T08:09:04.406Z | 2026-09-09T05:20:34.736Z |
|
||||
| 13 | 1 | unmet-truth | apps/web/src/app/globals.css | | Tailwind-4-Dunkelvariante war nie an die .dark-Klasse gebunden: globals.css definierte die Farbtokens unter .dark, deklarierte aber kein @custom-variant dark. In Tailwind 4 haengt die dark:-Utility-Variante per Vorgabe an prefers-color-scheme, nicht an einer Klasse. Die App schaltet den Modus jedoch ueber next-themes mit attribute=class. Folge: JEDE dark:-Utility im Web-Quellcode (ueber 100 Vorkommen in 10+ Dateien - Status-, Warn- und Fehlerfarben, Hinweisboxen, Badges in der Administration) blieb wirkungslos, sobald der Nutzer im Portal auf dunkel stellte, waehrend sein Betriebssystem hell stand. Am laufenden System gemessen: html.dark gesetzt, prefers-color-scheme hell, dark:bg-gray-800 ergab transparent und dark:text-green-400 blieb ohne Wirkung. Unentdeckt geblieben, weil Hintergrund und Textfarbe ueber CSS-Variablen unter .dark laufen und deshalb korrekt umschalten. Aufgedeckt beim Logo-Einbau 260907-fgv, dessen Plattenkontur dark:stroke-white/25 aus demselben Grund nicht griff. | fixed | | 2026-09-07T09:32:24.960Z | 2026-09-07T09:35:49.019Z |
|
||||
| 14 | 15 | unmet-truth | apps/web/src/app/(portal)/admin/modules/grants/page.tsx | | Die Suche in der Freigaben-Matrix macht die Matrix unbenutzbar, sobald sie etwas findet: derselbe Suchbegriff filtert BEIDE Achsen unabhaengig voneinander (page.tsx:137 filtert Module ueber m.name, page.tsx:145 filtert Gruppen ueber internalName/name). Ein Begriff, der nur eine Achse trifft, leert die andere vollstaendig — es bleibt nie ein Kaestchen zum Klicken uebrig. Am 2026-09-07 im Browser auf alpha gemessen: Suche 'Claude_VT' bzw. 'Vertrieb' laesst die Gruppenspalte stehen, entfernt aber jede Modulzeile; Suche 'Cert' laesst die Modulzeile stehen, entfernt aber jede Gruppenspalte. Damit scheitert genau der Zweck der Suche — in einer grossen Matrix die Kreuzung Modul x Gruppe finden. Belege: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/befund-matrix-suche-gruppenname.png und befund-matrix-suche-modulname.png | open | | 2026-09-07T12:46:56.172Z | |
|
||||
| 15 | 16 | unmet-truth | apps/api/src/ldap/ldap.service.ts | | Der Sync reicht rohe Techniktexte an den Administrator durch und laesst echte AD-Konten still liegen. Am 2026-09-07 auf alpha gegen das echte AD gemessen (Lauf 14:42): zehn Fehlerzeilen unter den drei Zahlenzeilen, davon zwei Sorten. (1) Vier Konten scheitern mit der woertlichen Prisma-Meldung 'Invalid prisma.user.create() invocation: Unique constraint failed on the fields: (email)' — CN=uvertrieb_ro, uvertrieb_rw, uvertrieb_ro_ss, usoftware_rw aus OU=CTL_PWS_Gruppen teilen sich offenbar eine E-Mail-Adresse. Sie werden dadurch NIE importiert, ohne dass der Administrator erfaehrt warum oder was er tun soll. (2) Sechs Eintraege melden englisch 'no username mapped (check sAMAccountName mapping)' — korrekt uebersprungene Kontakte/Ressourcen ohne sAMAccountName, aber die Meldung liest sich wie ein Fehler und ist nicht uebersetzt. Beides braucht eine verstaendliche deutsche Meldung; die E-Mail-Kollision zusaetzlich eine Entscheidung, ob solche Konten ohne E-Mail angelegt oder bewusst uebersprungen werden. Beleg: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6a-sync-zahlenzeilen.png | open | | 2026-09-07T12:47:32.058Z | |
|
||||
| 16 | 14 | unmet-truth | apps/api/src/tenders/tenders.controller.ts | | Das Postfach im Ausschreibungs-Radar hat keinen Verbindungstest, obwohl die Faehigkeit fertig vorliegt. Beide Inbox-Provider bringen testConnection() mit (imap.provider.ts:343, exchange-inbox.provider.ts:294), und das DKV-Modul nutzt sie ueber POST /dkv/test-connection samt Knopf 'Verbindung testen' im InboxConfigForm. Beim Ausschreibungs-Radar fehlt beides: der Controller kennt zu email-config nur GET (:343) und PUT (:357), kein Test-Endpunkt, und das Formular unter Meine Quellen hat keinen Knopf. Historie geprueft: der Knopf war nie vorhanden (git log -S testConnection im tender-radar-Frontend ist leer), es ist also eine Luecke, keine Regression. Folge fuer den Betrieb: ein Tippfehler in der EWS-Endpunkt-URL oder falsche Zugangsdaten fallen erst auf, wenn dauerhaft nichts ankommt — und dann ist nicht unterscheidbar, ob die Verbindung scheitert oder schlicht keine Alarm-Mail da war. Das trifft besonders WINDOWS #12, dessen ganzer Zweck der Beleg des handgeschriebenen NTLM/SOAP-Wegs ist. Aufgefallen am 2026-09-07 beim Einrichten des Postfachs. | open | | 2026-09-07T13:22:33.916Z | |
|
||||
| 16 | 14 | unmet-truth | apps/api/src/tenders/tenders.controller.ts | | Das Postfach im Ausschreibungs-Radar hat keinen Verbindungstest, obwohl die Faehigkeit fertig vorliegt. Beide Inbox-Provider bringen testConnection() mit (imap.provider.ts:343, exchange-inbox.provider.ts:294), und das DKV-Modul nutzt sie ueber POST /dkv/test-connection samt Knopf 'Verbindung testen' im InboxConfigForm. Beim Ausschreibungs-Radar fehlt beides: der Controller kennt zu email-config nur GET (:343) und PUT (:357), kein Test-Endpunkt, und das Formular unter Meine Quellen hat keinen Knopf. Historie geprueft: der Knopf war nie vorhanden (git log -S testConnection im tender-radar-Frontend ist leer), es ist also eine Luecke, keine Regression. Folge fuer den Betrieb: ein Tippfehler in der EWS-Endpunkt-URL oder falsche Zugangsdaten fallen erst auf, wenn dauerhaft nichts ankommt — und dann ist nicht unterscheidbar, ob die Verbindung scheitert oder schlicht keine Alarm-Mail da war. Das trifft besonders WINDOWS #12, dessen ganzer Zweck der Beleg des handgeschriebenen NTLM/SOAP-Wegs ist. Aufgefallen am 2026-09-07 beim Einrichten des Postfachs. | fixed | | 2026-09-07T13:22:33.916Z | 2026-09-09T05:20:09.851Z |
|
||||
|
||||
````json
|
||||
[
|
||||
@@ -173,10 +173,10 @@ last_updated: 2026-09-07T13:22:33.916Z
|
||||
"file": ".planning/phases/14-rss-email-alert-ingestion-module-rollout/14-03-PLAN.md",
|
||||
"line": null,
|
||||
"description": "14-03 Task 4 (checkpoint human-verify, gate blocking): echtes Portal-Alert-Postfach ueber den Exchange/EWS-Weg anbinden und eine echte Alarm-Mail ingestieren. Zu belegen sind (a) die Mail erzeugt eine mandantenprivate Ausschreibung, (b) ein anderer Mandant sieht sie nicht, (c) der EWS-Body-Abruf liefert nicht-leeren, nicht-verstuemmelten Inhalt gegen einen echten Exchange-Server. Der handgeschriebene NTLM/SOAP-Weg ist nur gegen gemocktes httpntlm.post geprueft, nie gegen einen echten Server. Braucht ein echtes Postfach - vom User am 2026-07-24 bewusst zurueckgestellt. Stand bisher nur in 14-VERIFICATION.md (status human_needed), nicht im Ledger.",
|
||||
"status": "open",
|
||||
"reason": "",
|
||||
"status": "waived",
|
||||
"reason": "Zurueckgestellt auf Entscheidung des Users vom 2026-09-09: es gibt intern derzeit KEIN Postfach, in das Ausschreibungs-Alarme hereinkommen — die Voraussetzung des Pruefpunkts existiert nicht. Ein frueheres Missverstaendnis hatte ein solches Postfach angenommen. Nachzuholen, sobald ein Alarm-Postfach eingerichtet ist: dann sind (a) mandantenprivate Ausschreibung aus der Mail, (b) Unsichtbarkeit fuer andere Mandanten und (c) nicht-leerer, nicht-verstuemmelter Nachrichtentext zu belegen. Teilentlastung vom 2026-09-09: der handgeschriebene NTLM/EWS-Weg wurde beim Test von #16 erstmals gegen den echten Exchange owa.ctl.de gemessen — Anmeldung, FindFolder und Ordneraufloesung funktionieren, belegt durch die echte ServerVersionInfo-Antwort (Exchange 15.2) im API-Protokoll. Der frueher als fragil markierte Verbindungsaufbau ist damit nicht mehr ungeprueft; offen bleibt allein das Einlesen einer echten Alarm-Mail.",
|
||||
"recorded_at": "2026-09-07T08:09:04.406Z",
|
||||
"resolved_at": null
|
||||
"resolved_at": "2026-09-09T05:20:34.736Z"
|
||||
},
|
||||
{
|
||||
"id": 13,
|
||||
@@ -221,10 +221,10 @@ last_updated: 2026-09-07T13:22:33.916Z
|
||||
"file": "apps/api/src/tenders/tenders.controller.ts",
|
||||
"line": null,
|
||||
"description": "Das Postfach im Ausschreibungs-Radar hat keinen Verbindungstest, obwohl die Faehigkeit fertig vorliegt. Beide Inbox-Provider bringen testConnection() mit (imap.provider.ts:343, exchange-inbox.provider.ts:294), und das DKV-Modul nutzt sie ueber POST /dkv/test-connection samt Knopf 'Verbindung testen' im InboxConfigForm. Beim Ausschreibungs-Radar fehlt beides: der Controller kennt zu email-config nur GET (:343) und PUT (:357), kein Test-Endpunkt, und das Formular unter Meine Quellen hat keinen Knopf. Historie geprueft: der Knopf war nie vorhanden (git log -S testConnection im tender-radar-Frontend ist leer), es ist also eine Luecke, keine Regression. Folge fuer den Betrieb: ein Tippfehler in der EWS-Endpunkt-URL oder falsche Zugangsdaten fallen erst auf, wenn dauerhaft nichts ankommt — und dann ist nicht unterscheidbar, ob die Verbindung scheitert oder schlicht keine Alarm-Mail da war. Das trifft besonders WINDOWS #12, dessen ganzer Zweck der Beleg des handgeschriebenen NTLM/SOAP-Wegs ist. Aufgefallen am 2026-09-07 beim Einrichten des Postfachs.",
|
||||
"status": "open",
|
||||
"status": "fixed",
|
||||
"reason": "",
|
||||
"recorded_at": "2026-09-07T13:22:33.916Z",
|
||||
"resolved_at": null
|
||||
"resolved_at": "2026-09-09T05:20:09.851Z"
|
||||
}
|
||||
]
|
||||
````
|
||||
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
# Abnahme im Browser — 2026-09-09
|
||||
|
||||
Durchgefuehrt auf **alpha** (https://alpha.tessera.ctl.de) gegen den echten
|
||||
Exchange-Server `owa.ctl.de`, nachdem die Container mit dem neuen Image neu
|
||||
erstellt wurden. Schliesst WINDOWS.md **#16**.
|
||||
|
||||
## Voraussetzung: Container tatsaechlich getauscht
|
||||
|
||||
Der blosse `pull` genuegte nicht — die Container liefen 41 Stunden alt weiter.
|
||||
Hart belegt statt vermutet: die neue Route war im gezogenen Image vorhanden und
|
||||
im laufenden Container nicht.
|
||||
|
||||
```
|
||||
laufender Container: grep "email-config/test" /app/apps/api/dist → nichts
|
||||
neues Image: grep "email-config/test" /app/apps/api/dist → 3 Treffer
|
||||
```
|
||||
|
||||
Nach `docker compose up -d --force-recreate api web` ist die Route gemappt:
|
||||
|
||||
```
|
||||
[RouterExplorer] Mapped {/modules/tender-radar/email-config/test, POST} route
|
||||
```
|
||||
|
||||
## Die vier Abnahmepunkte
|
||||
|
||||
| # | Pruefung | Ergebnis |
|
||||
|---|----------|----------|
|
||||
| 1 | Gespeicherte Konfiguration, **Passwortfeld leer** | **"Verbindung erfolgreich"** — belegt zugleich den Rueckgriff auf die gespeicherten verschluesselten Zugangsdaten, denn das Passwort wird nie an die Oberflaeche zurueckgegeben |
|
||||
| 2 | Absichtlich falscher Server (`owa-gibtsnicht.ctl.de`) | **"Verbindung fehlgeschlagen: getaddrinfo ENOTFOUND owa-gibtsnicht.ctl.de"** — rot, mit der echten Meldung |
|
||||
| 3 | Zugangsdaten im API-Protokoll | **keine.** Die drei Treffer einer Mustersuche waren Routennamen beim Start (`/auth/reset-password` und Geschwister), keine Daten |
|
||||
| 4 | Schreibt der Test etwas? | **nein** — die gespeicherte Konfiguration war nach beiden Laeufen unveraendert |
|
||||
|
||||
Belege: `uat-2026-09-09/w16-verbindung-erfolgreich.png`,
|
||||
`uat-2026-09-09/w16-verbindung-fehlgeschlagen.png`
|
||||
|
||||
## Nebenbefund mit Gewicht: der EWS-Weg laeuft gegen den echten Server
|
||||
|
||||
Das API-Protokoll des erfolgreichen Laufs zeigt eine **echte Antwort von Exchange
|
||||
2019**, nicht von einer Attrappe:
|
||||
|
||||
```
|
||||
[ExchangeInboxProvider] EWS FindFolder response for "DKV":
|
||||
<s:Header><h:ServerVersionInfo MajorVersion="15" MinorVersion="2"
|
||||
MajorBuildNumber="2562" MinorBuildNumber="46" .../></s:Header>
|
||||
[ExchangeInboxProvider] EWS FindFolder: resolved "DKV" → FolderId AAAQAGtzY2hhbGxlckBj…
|
||||
```
|
||||
|
||||
Damit ist der handgeschriebene NTLM/SOAP-Weg erstmals gegen einen echten
|
||||
Exchange-Server gemessen: Anmeldung, `FindFolder` und Ordneraufloesung
|
||||
funktionieren. Genau dieser Verbindungsaufbau war in Plan 14-03 als
|
||||
"documented-fragile" markiert und bisher nur gegen gemocktes `httpntlm.post`
|
||||
geprueft.
|
||||
|
||||
## Ausdruecklich NICHT belegt
|
||||
|
||||
Das Einlesen einer echten Alarm-Mail (WINDOWS #12). Dafuer gibt es intern derzeit
|
||||
kein Postfach, in das Ausschreibungs-Alarme hereinkommen — Entscheidung des Users
|
||||
vom 2026-09-09, der Punkt ist im Ledger zurueckgestellt. Der hier gepruefte Ordner
|
||||
`DKV` enthaelt Tankkarten-Rechnungen und diente nur als erreichbares Ziel fuer den
|
||||
Verbindungsaufbau.
|
||||
|
||||
## Beobachtung fuer spaeter (kein Mangel)
|
||||
|
||||
Der `ExchangeInboxProvider` schreibt die vollstaendige SOAP-Antwort als
|
||||
DEBUG-Zeile ins Protokoll. Das ist sehr gespraechig; Zugangsdaten stehen nicht
|
||||
darin, aber vor einem Produktivbetrieb waere zu ueberlegen, ob diese Ausgabe dort
|
||||
noch sinnvoll ist.
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Reference in New Issue
Block a user