Rückkanal: Caseverwaltung [ZSD 1.15.3]

Warum?

Relevante Links und Bemerkungen

• Mithilfe der in #510 (closed) eingestellten Client-ID im Case kann man nun implementieren:
  • Cases auflisten (GET /v1/cases)
  • Casedetails abrufen (GET /v1/cases/{caseId})
  • Case aktualisieren (offen halten, schließen) (PATCH /v1/cases/{caseId})

Akzeptanzkriterien

1. (outdated: 02.08.23) Der Case wurde in der Datenbank um einen Status caseState, der active oder closed sein kann, erweitert.
2. (outdated: 02.08.23) Der Case wurde in der Datenbank um ein Ablaufdatum closeTime (Zeitpunkt) erweitert. Nach Erreichen der closeTime wird der caseState auf closed gesetzt.
3. Sender und Subscriber können sich alle ihren aktiven (caseState == active) Cases auflisten lassen (GET /v1/cases)
4. Sender und Subscriber können die Details eines Cases abfragen (GET /v1/cases/{caseId})
5. (outdated: 02.08.23) Sender und Subscriber können einen Case offen halten (PATCH /v1/cases/{caseId} mit { "caseState": "active" }). Hierdurch wird die closeTime auf den Startwert zurückgesetzt.
6. (outdated: 02.08.23) Sender und Subscriber können einen Case schließen (PATCH /v1/cases/{caseId} mit { "caseState": "closed" }). Hierdurch wird der caseState auf closed gesetzt.
7. (outdated: 02.08.23) Wenn der caseState auf closed gesetzt, wird vom Zustelldienst ein Close Case Event erzeugt.
8. Der Zugriff des Senders wird über den sub Claim geprüft.
9. Der Zugriff des Subscribers wird über die Destination einer Submission des Cases geprüft.
10. Fehlercodes in API-Spec und Doku auf Vollständigkeit prüfen/korrigieren. → verschoben nach #1291 (closed) und #1227 (closed)
11. Entwurf der Event Payload Schemata wurde im Rahmen der Implementierung nochmals geprüft und bei Bedarf angepasst
12. NEU: (27.07.23) (outdated: 02.08.23) Der Endpunkt GET /cases/{uuid} wird erweitert um das Attribut bidirectional
13. NEU: (27.07.23) (outdated: 02.08.23) API-Spezifikation: bidirectional-Attribut in Response des GET /cases/{uuid} ergänzen
14. NEU: (27.07.23) Bei einem Berechtigungsfehler wird mit dem HTTP Status Code 403 geantwortet.
15. NEU: (27.07.23) Sender darf all seine Cases sehen (Prüfung des subject claims im Token)
16. NEU: (27.07.23) Subscriber: muss Scope subscribe:destination:<id> haben.
17. NEU: (02.08.23) Der CaseState und die CaseCloseTime sind wieder ausgebaut.

TODOs

• Bestehende Implementierung übernehmen und prüfen
• Akzeptanz Kriterien gegen den aktuellen Stand der Implementierung prüfen
• Spring Boot Tests für die bereits implementierten API Endpunkte umsetzen
• Ggf. Unit-Tests an kritischen Stellen "nach-implementieren"
• API Spezifikation anpassen:
  • manage:destination:<id> für die oben beschriebenen Endpunkte entfernen
  • (outdated 02.08.23) bidirectional-Flag bei dem GET-Endpunkt im Response Objekt zurückgeben
• Validierungsregeln in den Endpunkten überprüfen
• Event Payload Schemata nochmal prüfen
  • case-closed event fällt weg (NEU: 27.07.23)
• CaseState und CloseTime nach Entscheidung vom 27.07.23 und 02.08.23 wieder aus dem zustelldienst ausbauen
  • CaseState UND CloseTime aus der Api Spezifikation ausbauen → siehe submission-api!169 (merged)
  • CaseState UND CloseTime aus Datenbank ausbauen → erledigt mit https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/245/diffs?commit_id=bbbcc237a8b2f409606c7bf88a6784b3e10f7a83
  • CaseState UND CloseTime aus Java Code ausbauen → erledigt mit https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/245/diffs?commit_id=bbbcc237a8b2f409606c7bf88a6784b3e10f7a83
• Prüfen der Berechtigungsprüfung der Endpunkte der CaseApi (ggf. @PreAuthorize() nutzen)