Skip to content

Rückkanal: bidirectional-Flag in der Submission

Warum?

In der API wird in der neuen Spezifikation zum Rückkanal eine Flag ergänzt, um einen Case als bidirektionalen Case zu kennzeichnen: https://preview.docs.fitko.dev/submission-api/bilateral-communication/#post-/v1/submissions

Über den Flag wird sichergestellt, dass nach dem Empfang der Einreichung (Accept/Reject durch Subscriber) der Case für weitere Einreichungen oder Antworten geschlossen werden kann.

Relevante Links und Bemerkungen

  • Die Umsetzung des Close Status und Close Case Event nicht Teil dieser Story (Wird hier umgesetzt: #511 (closed))
    • Wird die Einreichung abgesendet (PUT /v1/submissions/{submissionId}) und bidirectional ist false, dann wird der Fall automatisch geschlossen (close-case), wenn ein Accept/Reject Event durch den Subscriber versendet wird.

Akzeptanzkriterien

  1. ALT: Beim Anlegen neuer Einreichungen (POST /v1/submissions) wird Das Flag bidirectional übernommen und gespeichert
  2. ALT: Wenn true, dann wird nur der Wert gespeichert. Es passiert nichts. Timer für true wird in #511 (closed) implementiert.
  3. ALT: Wird bidirectional nicht angegeben, ist das identisch zu false
    • Hinweis: Gängiges Verhalten von API-Clients, die den Minor API Change nicht implementieren
  4. NEU (27.07.23): Mit der ersten Submission in einem Case wird das Flag bidirectional gesetzt (Default: false). Das Flag kann später nicht mehr überschrieben werden.
  5. NEU (27.07.23): Bei Folgesubmissions (jede Submission nach der ersten Submission eines Cases) kommt es zu einem Fehler, wenn der Wert nicht mit dem im Case gespeicherten Wert übereinstimmt. Wird das Feld bidirectional bei Folgesubmissions nicht gesetzt, wird es ignoriert.
  6. NEU (02.08.23): Das bidirectional Flag wird erstmal nicht benötigt und wird 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:
    • (outdated 02.08.23) GET /v1/cases/<id> muss auch den gespeicherten Wert für bidirectional zurückgeben.
    • (outdated 02.08.23) Verhalten des Flags bei erster Submission und Folgesubmissions beschreiben (Regeln siehe ACs).
    • bidirectional Flag aus der API Spec wieder ausbauen
  • (outdated 02.08.23) Datenbank Migration schreiben: Feld bidirectional am Case.
  • bidirectional Flag nach Entscheidung vom 02.08.23 wieder aus dem zustelldienst ausbauen
  • ...
Edited by Jonas Gröger