BiDiKo: Reply nach Löschfrist löschen

Warum?

Damit die Datenbank auf Dauer nicht zu voll wird, sollen Antworten (Replies) nach bestimmten Löschfristen aus der Datenbank gelöscht werden. Hierfür gelten die gleichen Löschfristen wie bei der Submission (siehe auch bestehende Implementierung für Submissions). Anders als bei der Submission wird es vor dem Löschen keine Benachrichtigung per E-Mail geben.

Relevante Links und Bemerkungen

Löschung unvollständiger Antworten (Replies)

Unvollständige Antworten (Replies), die durch das sendende System (Fachverfahren) nicht abgeschlossen wurden und daher dem empfangenden System noch nicht bekannt sind, werden nach 1 Tag gelöscht.

Löschung bei nicht erfolgter Abholung

14 Tage nach Eingang einer neuen Antwort (Reply) in der FIT-Connect-Infrastruktur erfolgt eine Markierung der Antwort (Reply) als nicht-zustellbar ("reject-reply"-Event). Ab diesem Zeitpunkt können Antworten (Reply) nicht mehr abgerufen werden. Nach weiteren 7 Tagen, die zu Debugging-Zwecken benötigt werden, erfolgt anschließend eine Löschung der übermittelten Antwort (Reply).

Löschung von aktzeptierten oder rejecteden Antworten (Replies)

7 Tage nachdem eine Antwort akzeptiert oder rejected wurde, wird sie gelöscht.

Ein Reply gilt als gelöscht wenn:

• seine Attachments in der Datenbank gelöscht sind (Tabelle reply_attachment)
• die Felder data, metadata und announced_attachment gelöscht (bzw. mit null Wert) belegt sind.
• der Status des Replys auf DELETED gesetzt ist
• das Event delete-reply in das Event-Log geschrieben wird

Auswirkungen auf andere Endpunkte

Gelöschte Antworten (Replys) (Status=DELETED) werden in den folgenden Endpunkten nicht mehr zurückgegeben bzw. modifiziert:

• GET /v1/cases
• GET /v1/replies
• GET /v1/replies/<id>
• PUT /v1/replies/<id>
• PUT /v1/replies/<id>/accepted
• PUT /v1/replies/<id>/rejected
• GET /v1/replies/<id>/attachments/<id>
• PUT /v1/replies/<id>/attachments/<id>

Fristen siehe auch Benachrichtigungen und Löschfristen bei der Submission

Akzeptanzkriterien

1. Wenn eine Antwort (Reply) nach einem Tag noch nicht vollständig ist (Status = SUBMITTED), dann wird die Antwort (Reply) gelöscht.
2. Wenn es innerhalb von 14 Tagen keine Statusänderung bei einer Antwort (Reply) gibt, wird diese rejected. Dabei wird die Antwort (Reply) mit dem Status REJECTED versehen und das Event reject-reply geloggt.
3. Nach 7 Tagen werden Antworten (Replies), die den Status REJECTED haben gelöscht. Es wird das Event deleted-reply geloggt.
4. Nach 7 Tagen werden Antworten (Replies), die den Status ACCEPTED haben gelöscht. Es wird das Event deleted-reply geloggt.
5. Die oben genannten "Löschfristen" lassen sich per Konfiguration ändern.
6. Als gelöscht gekennzeichnete Antworten werden über keinen HTTP Endpunkt mehr nach außen zurückgegeben, auch keine einzelnen Bestandteile von ihnen.
7. Wird eine Antwort (Reply) als gelöscht markiert, dann werden die Daten aus den Feldern data, metadata und announced_attachment sowie alle Anhänge gelöscht bzw. mit null Werten belegt.
8. Gelöschte Antworten (Replys) (Status=DELETED) können über die oben genannten Endpunkte nicht mehr zurückgegeben bzw. modifiziert werden.

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

• Im Reply (Entity + Datenbank) ein Feld stateChangedAt o.ä. einführen (vergleiche Submission). → done with https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/278/diffs?commit_id=9eeb1408f39614cad467d9e63ac61ba87d3b3c24
• Das Feld stateChangedAt bei jedem StateChange aktualisieren. Hilft uns hier ggf. die JPA Annotation @PostUpdate? → über Setter des currentState gelöst → done with https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/278/diffs?commit_id=9eeb1408f39614cad467d9e63ac61ba87d3b3c24
• Konfigurationsmöglichkeit für die Löschfristen ähnlich wie bei der Submission umsetzen
  • delete-rejected-replies
  • delete-incomplete-replies
  • reject-submitted-replies
• Cron Jobs mit Jobrunr triggern
• Datanbankabfragen, die die jeweiligen Replies die unter eine Frist fallen, zurückgeben.
• Logik, die den Status der entsprechenden Replies aktualisiert, bzw. den Inhalt Löscht bzw. nullt.
• Felder im Reply löschen/leeren inkl. Anhänge.
• Anhänge (BLOBs) korrekt löschen. Siehe hier die Lösung aus #1097 (closed) → #1097 (comment 91024)
• ...

Fragen:

• Q: Soll es bei dem Event delete-reply einen Callback geben? Falls "JA" → an wen? Kann das zu einem späteren Zeitpunkt eingebaut werden?
  • A: 22.08.23: wenn es Zeit spart zu späterem Zeitpunkt in eigenem Ticket umsetzen → Ticket anlegen
  • A: 22.08.23: an wen geht der Callback? → wie bei Submission! (Erwartung: an beide Seiten)
  • A: 25.08.23: Bei dem Event delete-submission werden keine Callbacks erzeugt. Mit @Marco_Holz wurde besprochen, dass aus Konsistenzgründen auch bei einem delete-reply Event zunächst keine Callbacks erzeugt werden.
• Q: Welcher Zeitwert soll betrachtet werden?
  • a) Der Wert wenn sich der Reply (irgendein Feld) in der DB ändert?
  • b) Wenn sich der Zustand/Status des Reply verändert.
  • c) a) + b) kommt auf's gleiche raus? 🤔
  • A: → b) (wie bei Submission)