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}
)
- Cases auflisten (
Akzeptanzkriterien
-
(outdated: 02.08.23)
Der Case wurde in der Datenbank um einen StatuscaseState
, deractive
oderclosed
sein kann, erweitert. -
(outdated: 02.08.23)
Der Case wurde in der Datenbank um ein AblaufdatumcloseTime
(Zeitpunkt) erweitert. Nach Erreichen dercloseTime
wird dercaseState
aufclosed
gesetzt. -
Sender und Subscriber können sich alle
ihren aktiven (Cases auflisten lassen (caseState == active
)GET /v1/cases
) -
Sender und Subscriber können die Details eines Cases abfragen (
GET /v1/cases/{caseId}
) -
(outdated: 02.08.23)
Sender und Subscriber können einen Case offen halten (PATCH /v1/cases/{caseId}
mit{ "caseState": "active" }
). Hierdurch wird diecloseTime
auf den Startwert zurückgesetzt. -
(outdated: 02.08.23)
Sender und Subscriber können einen Case schließen (PATCH /v1/cases/{caseId}
mit{ "caseState": "closed" }
). Hierdurch wird dercaseState
aufclosed
gesetzt. -
(outdated: 02.08.23)
Wenn dercaseState
aufclosed
gesetzt, wird vom Zustelldienst ein Close Case Event erzeugt. -
Der Zugriff des Senders wird über den
sub
Claim geprüft. - Der Zugriff des Subscribers wird über die Destination einer Submission des Cases geprüft.
-
Fehlercodes in API-Spec und Doku auf Vollständigkeit prüfen/korrigieren.→ verschoben nach #1291 (closed) und #1227 (closed) - Entwurf der Event Payload Schemata wurde im Rahmen der Implementierung nochmals geprüft und bei Bedarf angepasst
-
NEU: (27.07.23) (outdated: 02.08.23)
Der EndpunktGET /cases/{uuid}
wird erweitert um das Attributbidirectional
-
NEU: (27.07.23) (outdated: 02.08.23)
API-Spezifikation:bidirectional
-Attribut in Response desGET /cases/{uuid}
ergänzen - NEU: (27.07.23) Bei einem Berechtigungsfehler wird mit dem HTTP Status Code 403 geantwortet.
- NEU: (27.07.23) Sender darf all seine Cases sehen (Prüfung des subject claims im Token)
-
NEU: (27.07.23) Subscriber: muss Scope
subscribe:destination:<id>
haben. - 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)