[Epic] Bidirektionale Kommunikation (Rückkanal)

Warum?

Es soll die Rückkanal Erweiterung der Submission implementiert werden. (Das ist kein Warum 😄 )

TODO

• Add more test for permission handling in https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/235
• Merge https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/235 in https://git.fitko.de/fit-connect/zustelldienst/-/tree/epic/bidirectional-communication
• Handle https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/236 (Issue #511)
• Handle https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/237 (Issue #512)
• Handle https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/238 (Issue #513)
• Inform the SDK team that OpenAPI 3.1.0 is used in the branch. They might want to test their model generation (if they do generate something). Ping @Klaus_Fischer and @Martin_Vogel.
• Check why pipeline fails in event-payload!1 (merged) → fixed it: event-payload@13a3539f
• HappyPath API Tests (ohne Callbacks)
• Release SET Schema 1.2.0 (currently released as 1.2.0-rc0)
• Release Metadatenschema 1.2.0 (currently released as 1.2.0-rc1)
• Release Submission API 1.3.0 (currently released as 1.3.0-rc2)
• Merge docs!180 (closed) in docs!426 (closed) by @Michael_Haidner.
• siehe TODOs in allen Stories

Links

• API Spec: #42
• API Spec MR: submission-api!167 (merged)
• Dokumentation der neuen Events: docs!180 (closed)
• Schema der neuen Events: event-payload!1 (merged)
• Initiale Ticketschnitte: https://md.darmstadt.ccc.de/rueckkanal-tickets

Akzeptanzkriterien

1. Die Implementierung der Submission API im Zustelldienst ist gemäß den Vorgaben aus #42 erfolgt.
2. Die neue Implementierung der Submission API im Zustelldienst und die neuen Schemata wurden auf Abwärtskompatibilität getestet. Ggf. auch mit den .Net und Java SDKs geprüft.
3. Die Implementierung im SSP ist gemäß den Vorgaben aus #42 erfolgt.
   • Destinations können mit den zusätzlichen Parametern für einen Rückkanal über FIT-Connect umgesetzt werden
   • Für Clients können die notwendigen Scopes hinterlegt werden
4. In der Dokumentation wurden alle Aspekte der Umsetzung durch Subscriber und Sender beschrieben.
5. Mit der Veröffentlichung der Dokumentation wurden auch die Aktualisierungen der API Spec und Schemata (Metadata und Security Event Token durchgeführt)
6. Die Einträge in den Collection-Resourcen sind zeitlich aufsteigend (neueste zuletzt) zu sortieren (ORDER BY id). Betrifft:
   • GET /v1/replies
   • GET /v1/cases
   • CaseInformation/caseMessages <- Hier reicht ORDER BY id nicht, da sie aus zwei Tabellen kommen.
7. Die spätere Umsetzung von #516 führt zu keinen Problemen.

Alte Sammlung von Akzeptanzkriterien und Issue-Verweisen

1. Die Implementierung im Zustelldienst ist gemäß den Vorgaben aus #42 erfolgt.
2. In der Dokumentation wurde das Rückkanal-Feature in einem Überblicks-Artikel beschrieben. -> #515
3. In der Dokumentation wurde das Rückkanal-Feature aus Sender-Sicht beschrieben. -> #515
4. In der Dokumentation wurde das Rückkanal-Feature aus Subscriber-Sicht beschrieben. -> #515
5. In der Dokumentation wurden alle neuen Events beschrieben (siehe https://git.fitko.de/fit-connect/konzepte/-/blob/main/Event_Log.md). -> #515
6. Im Glossar ist der Begriff processStandards definiert -> #514 (closed)
7. Die Einträge in den Collection-Resourcen sind zeitlich aufsteigend (neueste zuletzt) zu sortieren (ORDER BY id). Betrifft:
   • GET /v1/replies
   • GET /v1/cases
   • CaseInformation/caseMessages <- Hier reicht ORDER BY id nicht, da sie aus zwei Tabellen kommen.
8. Nach dem Schließen eines Cases dürfen keine Einreichungen und Antworten mehr begonnen oder abgesendet werden. Folgende Events dürfen nach einem close-case nicht mehr auftreten: create-submission, submit-submission, create-reply, submit-reply.
9. Der Zustelldienst prüft die Zugriffsberechtigung des Senders anhand des sub-Claims (Subject).
10. DVDV und Routing-Dienst / Routing API angepasst (Verbundendes Issue #278 prüfen)
11. SSP für FIT-Connect Rückkanal Option angepasst

Stories zur Umsetzung der Akzeptanzkriterien im EPIC

Backend Stories

• ✅ #506 (merged with epic/bidirectional-communication branch)
• #507 (merged with epic/bidirectional-communication branch)
• ✅ #509 (merged with epic/bidirectional-communication branch)
• ✅ #510 (merged with epic/bidirectional-communication branch)
• ✅ #511 (merged with epic/bidirectional-communication branch)
• ✅ #512
• ✅ #513 (merged with epic/bidirectional-communication branch)
• ✅ #1208 (merged with epic/bidirectional-communication branch)
• ✅ #1226

neue Stories nach PO Review (Teil 1):

• ✅ #1290
• #1291
• ✅ #1292
• #1293
• #1295

Ergänzend Umsetzung von folgendem Issue prüfen: #278 (aktuell in Buffer und nicht in Ready)

Frontend Stories

• #508

Doku Stories

• #115 / #515. MR: docs!426 (closed).
• #514 (closed)
• Callback Documentation (general): https://git.fitko.de/fit-connect/arch/-/blob/main/architecture/src/main/asciidoc/src/callbacks.adoc

Klärungspunkt: Wie sinnvoll die einzelnen Issues umsetzen und in Main mergen?

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

• Implementierung im Zustelldienst (API-Verhalten & Erstellung von SETs)
• Rückkanal-Möglichkeiten im SSP ist angepasst
• Aufnehmen ins Glossar: processStandards
• Die Client-IDDer Subject-Claim (sub) des Senders wird in den Case übernommen.
• Die Client-IDDer Subject-Claim (sub) aus dem Case wird bei allen Zugriffen des Senders geprüft. Achtung: Zugriffe des Subscribers werden weiterhin über die Destination geprüft.
• ...

Follow-Up Stories oder Epics

• Aufräumen der Callbacks (https://git.fitko.de/fit-connect/zustelldienst/-/blob/feature/1295-introduce-notify-reply-event/docs/callbacks.adoc?ref_type=heads) - z.B. warum wird der Sender via Callback informiert, dass er eine Submission angelegt oder versandt hat