Rückkanal: Reply anlegen / abschicken [ZSD 1.15.3]
- #510 (closed) und #511 (closed) müssen zunächst bearbeitet werden.
Warum?
Relevante Links und Bemerkungen
- Events schreiben
- Fast äquivalent zur Submission
- case werden in #510 (closed) erst behandelt, sodass dieses Issue zu 2/3 fertig gestellt wurde und bis dahin auf "blockiert" steht
Akzeptanzkriterien
-
Es ist möglich, ein Reply anzulegen ( POST /v1/replies
) wenn der Scopesubscribe:destination:<id>
im Token vorhanden ist -
Es ist möglich, ein Attachment eines Replys hochzuladen ( PUT /v1/replies/{replyId}/attachments/{attachmentId}
) wenn der Scopesubscribe:destination:<id>
im Token vorhanden ist -
Es ist möglich, ein Reply abzusenden ( PUT /v1/replies/{replyId}
) wenn der Scopesubscribe:destination:<id>
im Token vorhanden ist -
Die Events create-reply
undsubmit-reply
werden korrekt geschrieben -
Das Anlegen und Senden eines Replys ist nur möglich, wenn der referenzierte Case existiert -
Fehlercodes in API-Spec und Doku auf Vollständigkeit prüfen/korrigieren. Siehe #1291 (closed) und #1227 (closed) -
Entwurf der Event Payload Schemata wurde im Rahmen der Implementierung nochmals geprüft und bei Bedarf angepasst -
Die verschlüsselten Metadaten, Daten und Anlagen einer Antwort (Reply) werden auf die selbe Weise wie eine Einreichung (Submission) JWE-validiert.
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" -
Besprechen, ob und wie eine JWE Validierung implementiert wird. Ggf. ein Akzeptanzkriterium ergänze. -
JWEValidationService refactoren (er ist sehr stark auf die Submission ausgerichtet) -
JWE Validation für Reply Attachment -
JWE Validation für Reply Metadata -
JWE Validation für Reply Data
-
-
Callback Body für NEW_REPLY implementieren: https://git.fitko.de/fit-connect/zustelldienst/-/blob/epic/bidirectional-communication/src/main/java/de/fiep/zustelldienst/callbacks/CallbackBodyManager.java#L40-48 laut Spec:
{
"type": "https://schema.fitko.de/fit-connect/submission-api/callbacks/new-replies",
"replies": [
{
"replyId": "189ac564-c470-4000-81f0-55371471e301",
"caseId": "189ac564-c470-4000-8842-5b75884d0301",
"destinationId": "189ac564-c470-4000-8b0d-7de57eeef901"
}
]
}
→ Umgesetzt mit: https://git.fitko.de/fit-connect/zustelldienst/-/commit/908861511f0ebd447d40ee785f3d39d5fb14c77f?merge_request_iid=245
-
Berechtigungsprüfung bei den Reply Transfer Endpunkten korrigieren/fixen und refactoren → erledigt mit https://git.fitko.de/fit-connect/zustelldienst/-/commit/7bc418dc2b7d0793596d620b61c93c1b50131d8c?merge_request_iid=245 (Berechtigung) und https://git.fitko.de/fit-connect/zustelldienst/-/commit/f30026ef04d99c7f014315b904164719ae663aef?merge_request_iid=245 (Refactoring) -
Ggf. Zugriffs-Berechtigung (mit Scope subscribe:destination:<id>
) mit@SpringBootTest
testen -
Fix: Beim erzeugen der Events create-reply
undsubmit-reply
muss das JWT subjectreply:<id>
sein → erledigt mit https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/245/diffs?commit_id=3e6ec5e11b6a60c46f24fb0289efe627e09a7e8f -
...
Edited by Christoph Metzger