[Epic] Urlaubs-/Reise-Modul — Aggregation von Bildern, Buchungen, Dokumenten #323

New issue

Open

opened 2026-05-17 22:07:07 +02:00 by admin-mrrm · 0 comments

admin-mrrm commented

2026-05-17 22:07:07 +02:00

Owner

Vision

Ein Urlaubs-/Reise-Modul, das alle Daten und Artefakte eines Urlaubs an einem Ort zusammenführt — automatisch erkannt aus existierenden Datenquellen (Mails, Dokumente, Bilder), nicht händisch zusammengeklickt.

Eine Reise als zentrale Entität soll als "Tagebuch" rückblickend beantworten:

Wann waren wir wo? Wie lange?
Welche Buchungen (Hotel/Flug/Mietwagen/Ferienhaus) gab es?
Welche Bilder sind in dem Zeitraum entstanden?
Welche Belege/Rechnungen liegen dazu im Paperless?
Welche Ausflüge / Aktivitäten haben wir gemacht (Todos, Mail-Bestätigungen)?
Welche Listen (Packliste, Einkaufsliste) gab es?

Architektur

Das Feature ist ein direktes Schwester-Modul zum bestehenden tracking-Modul — selbes Muster, andere Domain:

                    +--------------+
   IMAP-Mails  ---> | booking-     |
                    | parser       |  (analog tracking-parser)
                    +------+-------+
                           v
                    +--------------+
                    |  trips       |  (neues Modul)
                    |  Entity      |
                    |  - title     |
                    |  - period    |
                    |  - location  |
                    +------+-------+
                           | aggregiert per Zeitraum/Tag
        +------------------+------------------+
        v                  v                  v
  +----------+      +----------+      +----------+
  | Immich   |      |Paperless |      | Lists/   |
  | (Photos) |      |(Docs)    |      | Todos    |
  +----------+      +----------+      +----------+
        ^                  ^                  ^
        |                  |                  |
   Bilder im          Belege im           Packliste,
   Zeitraum           Zeitraum            Ausflüge,
                                          Einkaufsliste

Neue API-Module

apps/api/src/modules/trips/
- trips.schema.ts — Tabellen trips, trip_bookings
  - trips: id, ownerSub, title, startDate, endDate, destination, notes, ...
  - trip_bookings: id, tripId, kind (hotel/flight/car/rental), provider, reference, sourceMailId -> mailMessagesCache
- trips.service.ts + .controller.ts analog zu bestehenden Modulen
apps/api/src/modules/booking-parser/ (analog tracking-parser/)
- Erkennt Buchungs-Mails (Booking.com, Airbnb, Lufthansa, Sixt, ...) per Absender + Pattern
- Extrahiert Zeitraum + Ort + Buchungstyp
apps/api/src/modules/immich/ (neuer Client)
- REST-Client gegen Immich (/api/search/metadata mit takenAfter/takenBefore)
- Aggregiert Bilder für einen Trip-Zeitraum
- Optional: Trip-Tag in Immich zurueckschreiben

Anpassungen bestehender Module

mail-scanner (in tracking/): zweite Pipeline fuer booking-parser daneben oder Service generalisieren
lists: optionale tripId-Spalte (nullable Migration) -> Packlisten/Einkaufslisten an Trip haengen
documents: Paperless nach Zeitraum filtern (existiert vermutlich schon, oder leichte Erweiterung)
mail-tags: System-Tag trip:<id> fuer Mails im Trip-Zeitraum (bestehendes Tag-System)

UI

Neues Package packages/feature-trips/ (analog feature-tracking)
Trip-Listen-View + Trip-Detail-View, die alle Datenquellen aggregiert darstellt
Web + Mobile (Tamagui -> keine Doppelimplementierung)

Phasen

Phase 1 — Manuelle Trips + Immich-Aggregation (Quick Win)

Mehrwert sofort sichtbar, kein Parser-Risiko.

Schema trips + Drizzle-Migration
CRUD-Controller/-Service fuer Trips
Immich-Client + Endpoint GET /trips/:id/photos (per Zeitraum)
UI: Trip anlegen, Liste anzeigen, Detail-View mit Foto-Grid

Phase 2 — Buchungs-Mail-Parser -> Auto-Trips

booking-parser-Modul mit ersten 2-3 Anbietern (z.B. Booking.com, Lufthansa, Sixt)
Erweiterung Mail-Scanner: erkannte Buchungen -> trip_bookings
Heuristik: Buchungen im selben Zeitfenster zu einem trip zusammenfassen (manuell bestaetigen)

Phase 3 — Volle Aggregation

Paperless-Filter pro Trip-Zeitraum
lists.tripId Migration + UI zum Zuordnen einer Liste zu einem Trip
Mail-Auto-Tagging mit trip:<id>
Trip-Detail-View zeigt: Bilder, Buchungen, Dokumente, Listen/Todos, Mails — auf einer Seite

Phase 4 — Nice-to-have

Geo-Daten aus Foto-Metadaten (EXIF GPS) -> automatische Routen-Visualisierung
Trip-Export (PDF / statische HTML-Seite)
Immich-seitiges Album-Anlegen pro Trip

Offene Fragen

Immich-Auth: Wie wird auf den eigenen Immich-Server zugegriffen? API-Key pro User oder Service-Account?
Booking-Parser: Welche Anbieter haben Prioritaet? Haengt davon ab, welche Buchungs-Mails real eintreffen.
Trip-Erkennung: Soll die App automatisch Trip-Vorschlaege generieren (z.B. "2 Buchungen im selben Zeitraum entdeckt — Trip anlegen?") oder rein manuell?
Privacy: Daten bleiben wie gewohnt selbst gehostet — keine externen Calls ausser zu eigenen Diensten (Immich, Paperless).

Bezug zu existierenden Modulen

tracking/ + tracking-parser/ — direkte Vorlage fuer Architektur
mail/ — Mail-Abruf, Tag-System, Sender-Memory schon vorhanden
documents/ + Paperless-Client — bereits integriert
lists/ — Listen-Container, nur tripId-Spalte fehlt

## Vision Ein **Urlaubs-/Reise-Modul**, das alle Daten und Artefakte eines Urlaubs an einem Ort zusammenführt — automatisch erkannt aus existierenden Datenquellen (Mails, Dokumente, Bilder), nicht händisch zusammengeklickt. Eine Reise als zentrale Entität soll als "Tagebuch" rückblickend beantworten: - Wann waren wir wo? Wie lange? - Welche Buchungen (Hotel/Flug/Mietwagen/Ferienhaus) gab es? - Welche Bilder sind in dem Zeitraum entstanden? - Welche Belege/Rechnungen liegen dazu im Paperless? - Welche Ausflüge / Aktivitäten haben wir gemacht (Todos, Mail-Bestätigungen)? - Welche Listen (Packliste, Einkaufsliste) gab es? --- ## Architektur Das Feature ist ein **direktes Schwester-Modul zum bestehenden `tracking`-Modul** — selbes Muster, andere Domain: ``` +--------------+ IMAP-Mails ---> | booking- | | parser | (analog tracking-parser) +------+-------+ v +--------------+ | trips | (neues Modul) | Entity | | - title | | - period | | - location | +------+-------+ | aggregiert per Zeitraum/Tag +------------------+------------------+ v v v +----------+ +----------+ +----------+ | Immich | |Paperless | | Lists/ | | (Photos) | |(Docs) | | Todos | +----------+ +----------+ +----------+ ^ ^ ^ | | | Bilder im Belege im Packliste, Zeitraum Zeitraum Ausflüge, Einkaufsliste ``` ### Neue API-Module - **`apps/api/src/modules/trips/`** - `trips.schema.ts` — Tabellen `trips`, `trip_bookings` - `trips`: `id`, `ownerSub`, `title`, `startDate`, `endDate`, `destination`, `notes`, ... - `trip_bookings`: `id`, `tripId`, `kind` (hotel/flight/car/rental), `provider`, `reference`, `sourceMailId` -> `mailMessagesCache` - `trips.service.ts` + `.controller.ts` analog zu bestehenden Modulen - **`apps/api/src/modules/booking-parser/`** (analog `tracking-parser/`) - Erkennt Buchungs-Mails (Booking.com, Airbnb, Lufthansa, Sixt, ...) per Absender + Pattern - Extrahiert Zeitraum + Ort + Buchungstyp - **`apps/api/src/modules/immich/`** (neuer Client) - REST-Client gegen Immich (`/api/search/metadata` mit `takenAfter`/`takenBefore`) - Aggregiert Bilder für einen Trip-Zeitraum - Optional: Trip-Tag in Immich zurueckschreiben ### Anpassungen bestehender Module - **`mail-scanner`** (in `tracking/`): zweite Pipeline fuer `booking-parser` daneben oder Service generalisieren - **`lists`**: optionale `tripId`-Spalte (nullable Migration) -> Packlisten/Einkaufslisten an Trip haengen - **`documents`**: Paperless nach Zeitraum filtern (existiert vermutlich schon, oder leichte Erweiterung) - **`mail-tags`**: System-Tag `trip:<id>` fuer Mails im Trip-Zeitraum (bestehendes Tag-System) ### UI - Neues Package `packages/feature-trips/` (analog `feature-tracking`) - Trip-Listen-View + Trip-Detail-View, die alle Datenquellen aggregiert darstellt - Web + Mobile (Tamagui -> keine Doppelimplementierung) --- ## Phasen ### Phase 1 — Manuelle Trips + Immich-Aggregation (Quick Win) Mehrwert sofort sichtbar, kein Parser-Risiko. - [ ] Schema `trips` + Drizzle-Migration - [ ] CRUD-Controller/-Service fuer Trips - [ ] Immich-Client + Endpoint `GET /trips/:id/photos` (per Zeitraum) - [ ] UI: Trip anlegen, Liste anzeigen, Detail-View mit Foto-Grid ### Phase 2 — Buchungs-Mail-Parser -> Auto-Trips - [ ] `booking-parser`-Modul mit ersten 2-3 Anbietern (z.B. Booking.com, Lufthansa, Sixt) - [ ] Erweiterung Mail-Scanner: erkannte Buchungen -> `trip_bookings` - [ ] Heuristik: Buchungen im selben Zeitfenster zu einem `trip` zusammenfassen (manuell bestaetigen) ### Phase 3 — Volle Aggregation - [ ] Paperless-Filter pro Trip-Zeitraum - [ ] `lists.tripId` Migration + UI zum Zuordnen einer Liste zu einem Trip - [ ] Mail-Auto-Tagging mit `trip:<id>` - [ ] Trip-Detail-View zeigt: Bilder, Buchungen, Dokumente, Listen/Todos, Mails — auf einer Seite ### Phase 4 — Nice-to-have - [ ] Geo-Daten aus Foto-Metadaten (EXIF GPS) -> automatische Routen-Visualisierung - [ ] Trip-Export (PDF / statische HTML-Seite) - [ ] Immich-seitiges Album-Anlegen pro Trip --- ## Offene Fragen - **Immich-Auth**: Wie wird auf den eigenen Immich-Server zugegriffen? API-Key pro User oder Service-Account? - **Booking-Parser**: Welche Anbieter haben Prioritaet? Haengt davon ab, welche Buchungs-Mails real eintreffen. - **Trip-Erkennung**: Soll die App automatisch Trip-Vorschlaege generieren (z.B. "2 Buchungen im selben Zeitraum entdeckt — Trip anlegen?") oder rein manuell? - **Privacy**: Daten bleiben wie gewohnt selbst gehostet — keine externen Calls ausser zu eigenen Diensten (Immich, Paperless). --- ## Bezug zu existierenden Modulen - `tracking/` + `tracking-parser/` — direkte Vorlage fuer Architektur - `mail/` — Mail-Abruf, Tag-System, Sender-Memory schon vorhanden - `documents/` + Paperless-Client — bereits integriert - `lists/` — Listen-Container, nur `tripId`-Spalte fehlt