Skip to content
Snippets Groups Projects

Rückkanal: Abholen von Replies

    • Closed Issue created by Jonas Gröger @Jonas_Groeger

    Warum?

    Relevante Links und Bemerkungen

    • Umsetzung nach Fertigstellung der Spezifikation #42 (closed)

    Akzeptanzkriterien

    1. Der Sender kann sich Replys auflisten lassen (GET /v1/replies). Auflistung erfolgt anhand der Client-ID im Access Token Sub Claim.
    2. Der Sender kann ein Reply abrufen (GET /v1/replies/{replyId})
    3. Der Sender kann ein Attachment eines Reply abrufen (GET /v1/replies/{replyId}/attachments/{attachmentId})
    4. Der Sender kann ein Reply akzeptieren (PUT /v1/replies/{replyId}/accept). Es wird ein accept-reply Event durch den Zustelldienst erzeugt. Es wird der Public Key des Zustelldienst zur Signatur genutzt, der auch bei anderen Security Event Tokens des Zustelldienstes genutzt wird.
    5. Der Sender kann ein Reply zurückweisen (PUT /v1/replies/{replyId}/reject). Es wird ein reject-reply Event durch den Zustelldienst erzeugt. Es wird der Public Key des Zustelldienst zur Signatur genutzt, der auch bei anderen Security Event Tokens des Zustelldienstes genutzt wird.
    6. Der Sender kann nur auf Replys im Status submitted zugreifen (siehe Statusdiagramm)
    7. Fehlercodes in API-Spec und Doku auf Vollständigkeit prüfen/korrigieren → verschoben nach #1291 (closed) und #1227 (closed)
    8. Entwurf der Event Payload Schemata wurde im Rahmen der Implementierung nochmals geprüft und bei Bedarf angepasst

    TODOs

    • Bestehende Implementierung übernehmen und prüfen
    • Akzeptanz Kriterien der aktuellen Implementierung prüfen
    • Spring Boot Tests für die bereits implementierten API Endpunkte umsetzen
    • Ggf. Unit-Tests an kritischen Stellen "nach-implementieren"
    • Endpunkt PUT /v1/replies/{replyId}/accept umsetzen
    • Endpunkt PUT /v1/replies/{replyId}/reject umsetzen
    • Internes Status-Model für Replies mit den Zuständen INCOMPLETE, SUBMITTED, ACCEPTED, REJECTED, (DELETED) implementiert
      • INCOMPLETE, SUBMITTED, ACCEPTED, REJECTED
      • (DELETED) ? → #1208 (closed)
    • Refactoring: Zugriffskontrolle mittels @PreAuthroize
    • Zugriffskontrolle für GET /v1/replies fehlt und muss implementiert werden
    • Endpunkt PUT /v1/replies//accept umsetzten
      • inkl. AuthenticationTag Validator
    • Endpunkt PUT /v1/replies//reject umsetzen → erledigt mit https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/245/diffs?commit_id=0959d9a863b61e07fdde365d83ae28df9c07ae8c
      • [ ]
    • Prüfen: Callbacks für accept und reject mit bestehender Implementierung oder erst im Nachgang (→ Story erstellen)
      • Implementiere Callback für Subscriber wenn Reply accepted oder rejected wird (NewEvent callback)
    • Notify-Reply Event nach senden des Callbacks implementieren und erneut Callback versenden?
    • Delete-Reply Event Implementieren oder aus SET-Schema herausnehmen
    • Die GET Endpunkte in ReplyRetrievalAPI nutzen noch kein @PreAuthroize
    • ...
    • Definition of Done wurde geprüft
    25 of 29 checklist items completed · Edited

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply