Protokoll-Historie

Die Route app/pages/history.vue zeigt lokal vorhandene Protokolle, serverseitig vorhandene Protokolle ohne lokale Kopie und lokale Protokolle, die auf dem Server fehlen.

Datenquellen

app/composables/protocol/useProtocolHistoryPage.ts orchestriert die Historie.

Verwendete Quellen:

• IndexedDB: acceptanceHelpers.getAll() für lokal gespeicherte Acceptances
• Server: GET /acceptance/all für den aktuellen Server-Snapshot
• Server: GET /acceptance/free für Verträge, aus denen noch Protokolle erstellt werden können

Die lokale Liste wird mit Serverdaten angereichert, wenn ein Server-Snapshot vorhanden ist. Dabei werden Metadaten wie Mieter, Vertrag, Wohnung, Lock-Status und Clone-Quelle aus dem Serverstand übernommen.

Gruppierung

Die sichtbaren lokalen Protokolle werden nach Mieter gruppiert.

HistoryClientGroupCard.vue rendert pro Mieter eine aufklappbare Gruppe. Die einzelnen Zeilen kommen aus HistoryProtocolRow.vue und bieten:

• Öffnen des Protokolls
• lokalen Löschvorgang
• JSON-Export, wenn das Protokoll serverseitig fehlt

Das Öffnen verwendet getAcceptanceRouteLocation(...):

• gesperrte oder pending-upload Acceptances öffnen /finalize?acceptance=<id>
• bearbeitbare Acceptances öffnen /?acceptance=<id>

Server-Only-Protokolle

remoteOnlyAcceptances enthält Protokolle, die der Server kennt, aber die lokale IndexedDB nicht.

HistoryRemoteOnlyCard.vue zeigt diese Protokolle separat als Server-Protokolle an. Beim Öffnen navigiert die App direkt zur passenden Acceptance-Route. Die eigentliche Hydration läuft anschließend über Middleware, Acceptance-Store und Entity-Sync.

Server-gelöschte lokale Protokolle

Wenn ein Server-Snapshot geladen wurde und eine lokale Acceptance darin fehlt, markiert die Historie den Eintrag als serverDeleted.

Beim Klick auf ein solches Protokoll öffnet HistoryServerDeletedModal.vue statt direkt zu navigieren.

Der Dialog bietet:

• JSON-Export über useProtocolExport().exportAsJSON(id)
• Fortfahren zum lokalen Protokoll
• Abbrechen

Die Sammelaktion im Header löscht alle lokal vorhandenen, serverseitig fehlenden Protokolle aus IndexedDB.

Wenn dagegen beim konkreten Öffnen oder Hydrieren GET /acceptance/<id> mit 404 oder 410 antwortet, gilt der Serverstand als maßgeblich. Die App entfernt die lokale Acceptance inklusive Sektionsdaten aus IndexedDB und leitet nach /history?missingAcceptance=<id> zurück. Die Historie zeigt dazu ein Info-Modal; Editor und Kundenansicht dürfen keine alten lokalen Protokolldaten mehr anzeigen.

Demo-Erstellung

Wenn freie Verträge vorhanden sind, kann die Historie ein Demo-Protokoll erstellen.

Der Flow nimmt den ersten Vertrag mit verfügbaren Typen, erstellt den ersten verfügbaren Typ über useAcceptanceApi().createAcceptance(...), aktualisiert die freien Verträge und navigiert danach direkt in den Editor.

Dieser Pfad ist produktiver UI-Code der Historie; er erzeugt trotzdem echte Acceptances über denselben API-Endpunkt wie /create.

Export

app/composables/protocol/useProtocolExport.ts exportiert lokale Acceptance-Daten als JSON-Datei.

Der Export liest über acceptanceHelpers.exportAsJSON(id), erstellt einen Blob und lädt protokoll-{id}.json herunter. Er ist bewusst ein lokaler Rettungspfad für Protokolle, deren Serverstatus unsicher oder gelöscht ist.