E-Mail-Detailansicht & Thread-Darstellung fuer web/mail-postfach. Baut auf UX-01s offenem Branch auf (PR #298, noch nicht gemergt) - enthaelt daher UX-01s Commits mit.
Backend: neuer Endpunkt GET /api/v1/mail/messages/{messageID}/attachments (reiner Pass-through bestehender Storage-Funktionen). Frontend: Thread-Gruppierung ueber Betreff-Praefix-Normalisierung (keine RFC In-Reply-To/References Header in der Ingestion-Pipeline vorhanden, dokumentierte Systemgrenze), Navigation ohne Routenwechsel (Context-Erhalt strukturell statt nur konventionell).
Hinweis zu UX-03 (ebenfalls offener PR #297, separate App web/mail-search statt web/mail-postfach): keine Komponenten-Wiederverwendung moeglich/sinnvoll, eigene einfache Anhangsliste statt Vorschau gebaut. Beide Branches haben unabhaengig denselben Attachment-Listen-Endpunkt hinzugefuegt - muss bei Zusammenfuehrung auf main abgeglichen werden (im Pruefprotokoll dokumentiert).
AC1-3 real getestet (61/61 Frontend-Tests, 21/21 Go-Tests gruen), inkl. echtem Fixture-Prozess mit 3-teiligem Thread und 2 echten Anhaengen.
E-Mail-Detailansicht & Thread-Darstellung fuer web/mail-postfach. Baut auf UX-01s offenem Branch auf (PR #298, noch nicht gemergt) - enthaelt daher UX-01s Commits mit.
Backend: neuer Endpunkt GET /api/v1/mail/messages/{messageID}/attachments (reiner Pass-through bestehender Storage-Funktionen). Frontend: Thread-Gruppierung ueber Betreff-Praefix-Normalisierung (keine RFC In-Reply-To/References Header in der Ingestion-Pipeline vorhanden, dokumentierte Systemgrenze), Navigation ohne Routenwechsel (Context-Erhalt strukturell statt nur konventionell).
Hinweis zu UX-03 (ebenfalls offener PR #297, separate App web/mail-search statt web/mail-postfach): keine Komponenten-Wiederverwendung moeglich/sinnvoll, eigene einfache Anhangsliste statt Vorschau gebaut. Beide Branches haben unabhaengig denselben Attachment-Listen-Endpunkt hinzugefuegt - muss bei Zusammenfuehrung auf main abgeglichen werden (im Pruefprotokoll dokumentiert).
AC1-3 real getestet (61/61 Frontend-Tests, 21/21 Go-Tests gruen), inkl. echtem Fixture-Prozess mit 3-teiligem Thread und 2 echten Anhaengen.
Siehe mail/docs/UX-02-PRUEFPROTOKOLL.md.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
patrick
added 6 commits 2026-10-16 09:20:23 +02:00
Erweitert mail/internal/mailapi (INT-01) um die fuer die Postfach-/
Ordneransicht noetigen Daten, die die bestehende API noch nicht lieferte:
GET /mailboxes (Ordnerbaum aus der mailbox-Facette), mailbox-Filter auf
GET /messages, sowie sender/mailbox in der Listenantwort (Grundlage fuer
Sortierung nach Absender). Reines Durchreichen bereits fertiger
mail/internal/search-Funktionen (Facets/ListByMailbox/SearchWithFilters),
keine neue Suchlogik.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Testinfrastruktur: startet den echten mailapi.Server (echte moduleauth-
Signaturpruefung) als eigenen Prozess auf einem echten TCP-Port, mit
In-Memory-Suchpersistenz und zwei synthetischen Mandanten (einer davon
mit 3000 Nachrichten fuer den Performance-Nachweis). Grundlage fuer den
Frontend-Integrationstest gegen eine echte Backend-API statt eines
fetch()-Mocks. Kein Produktivpfad.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Postfach- und Ordneransicht fuer archivierte Mails (Next.js/React/TS,
@nexarch/shl). Ordnerbaum (aus der flachen Postfachliste der Mail-API
clientseitig aufgebaut), virtualisierte Nachrichtenliste mit Sortierung
nach Datum/Absender/Betreff, Grundsuche. Aufbau nach etabliertem Muster
(web/mail-search fuer die App-Struktur, web/dms-browser fuer Ordnerbaum/
virtualisierte Liste), bewusst schlicht gehalten (Mailpit/MailHog als
Vorbild, nicht die Komplexitaet eines nativen Mailprogramms).
Automatisierte Tests je Akzeptanzkriterium, inkl. eines echten
Backend-Integrationstests (e2e/ux01.e2e.test.ts) gegen den echten
mailapi.Server (mail/cmd/mailpostfach-fixture) mit zwei Mandanten und
einem gleichnamigen Ordner — keine Mandanten-Isolationslogik wird
gemockt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pruefprotokoll: Zielwerte und Ergebnisse je Akzeptanzkriterium und
Pruefung, inkl. Abgrenzung zur Ausgangslage (Backend-API musste fuer
Ordnerbaum/Absender-Sortierung minimal erweitert werden) und offener
Einschraenkung beim manuellen Test (keine Browser-Automatisierung/kein
laufender Core-Server auf dem Entwicklungshost, daher Ersatzpruefung
ueber den echten Backend-Integrationstest).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Backend-Grundlage fuer die Detailansicht: GET /messages/{id}/attachments
(Index/ContentType/Size per Magic-Bytes, kein Dateiname -- der
Ingestion-Pfad persistiert nirgends einen Originaldateinamen) ergaenzt
die bestehende mailapi (bereits vorhandenes Detail-Endpoint liefert
Subject/Body/Sender/Mailbox/SentAt bereits vollstaendig als Header-Basis).
Unabhaengig von UX-03 (eigener offener Branch, anderes Frontend
web/mail-search) mit gleicher Endpunktform implementiert, da UX-02 auf
UX-01 aufsetzt, nicht auf UX-03 -- Integration/Merge-Konflikt ist Sache
eines spaeteren Zusammenfuehr-Schritts, siehe UX-02-PRUEFPROTOKOLL.md.
Fixture (mail/cmd/mailpostfach-fixture) um einen 3-teiligen Thread samt
zwei echten Anhaengen erweitert, fuer den e2e-Test des Frontends gegen
die echte Backend-API -- bestehende UX-01-Ordner/-Zaehlungen bleiben
unveraendert gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Detailansicht fuer web/mail-postfach (UX-01-App erweitert, nicht neu
gebaut): Header (Von/Betreff/Ordner/Datum/Nachricht-ID), Nachrichtentext,
Anhangsliste mit Download (Dateiname nicht verfuegbar -- System
persistiert keinen Originalnamen, daher Anhang N + aus dem
Content-Type geratene Endung). Thread-Gruppierung ueber normalisierten
Betreff (keine In-Reply-To/References-Header im System), Navigation
zwischen Thread-Nachrichten als reiner Komponentenzustand derselben
Seite (kein Routenwechsel -- Ordner-/Suchkontext bleibt dadurch
strukturell erhalten, Akzeptanzkriterium 3).
UX-03 (eigener offener Branch, eigenes Frontend web/mail-search) wird
NICHT wiederverwendet -- getrennte Apps ohne Komponentenfreigabe, siehe
UX-02-PRUEFPROTOKOLL.md fuer die Abgrenzung und die Begruendung der
Backend-Erweiterung.
Tests: lib/threading, lib/threadNavigation, lib/attachmentNaming,
components/MessageDetail (Komponententest je Akzeptanzkriterium),
__tests__/a11y (jest-axe, Pruefung 3), e2e/ux02 gegen die echte
mailpostfach-fixture (Pruefungen 1+2, Mandantentrennung). Bestehender
e2e/ux01-Satz bleibt unveraendert gruen.
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.
E-Mail-Detailansicht & Thread-Darstellung fuer web/mail-postfach. Baut auf UX-01s offenem Branch auf (PR #298, noch nicht gemergt) - enthaelt daher UX-01s Commits mit.
Backend: neuer Endpunkt GET /api/v1/mail/messages/{messageID}/attachments (reiner Pass-through bestehender Storage-Funktionen). Frontend: Thread-Gruppierung ueber Betreff-Praefix-Normalisierung (keine RFC In-Reply-To/References Header in der Ingestion-Pipeline vorhanden, dokumentierte Systemgrenze), Navigation ohne Routenwechsel (Context-Erhalt strukturell statt nur konventionell).
Hinweis zu UX-03 (ebenfalls offener PR #297, separate App web/mail-search statt web/mail-postfach): keine Komponenten-Wiederverwendung moeglich/sinnvoll, eigene einfache Anhangsliste statt Vorschau gebaut. Beide Branches haben unabhaengig denselben Attachment-Listen-Endpunkt hinzugefuegt - muss bei Zusammenfuehrung auf main abgeglichen werden (im Pruefprotokoll dokumentiert).
AC1-3 real getestet (61/61 Frontend-Tests, 21/21 Go-Tests gruen), inkl. echtem Fixture-Prozess mit 3-teiligem Thread und 2 echten Anhaengen.
Siehe mail/docs/UX-02-PRUEFPROTOKOLL.md.
🤖 Generated with Claude Code
Backend-Grundlage fuer die Detailansicht: GET /messages/{id}/attachments (Index/ContentType/Size per Magic-Bytes, kein Dateiname -- der Ingestion-Pfad persistiert nirgends einen Originaldateinamen) ergaenzt die bestehende mailapi (bereits vorhandenes Detail-Endpoint liefert Subject/Body/Sender/Mailbox/SentAt bereits vollstaendig als Header-Basis). Unabhaengig von UX-03 (eigener offener Branch, anderes Frontend web/mail-search) mit gleicher Endpunktform implementiert, da UX-02 auf UX-01 aufsetzt, nicht auf UX-03 -- Integration/Merge-Konflikt ist Sache eines spaeteren Zusammenfuehr-Schritts, siehe UX-02-PRUEFPROTOKOLL.md. Fixture (mail/cmd/mailpostfach-fixture) um einen 3-teiligen Thread samt zwei echten Anhaengen erweitert, fuer den e2e-Test des Frontends gegen die echte Backend-API -- bestehende UX-01-Ordner/-Zaehlungen bleiben unveraendert gruen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Groesster Konflikt der Runde (add/add bei MessageDetail), manuell geloest, 82/82 Frontend-Tests + Go-Tests gruen, direkt in main gemergt und gepusht.
Pull request closed