Rückkanal: Destinationmanagement (`replyChannels`)

Warum?

• Im Rahmen der API-Spezifikation wird replyChannels in das services Objekt verschoben, da das Rückkanal Angebot leistungsspezifisch ist.
• Aufgrund dessen wird replyChannels auf Ebene der Destination als deprecated markiert.
• Da der Rückkanal als Minor Release umgesetzt wird, soll replyChannels auf Ebene der Destination weiterhin nutzbar sein.

Relevante Links und Bemerkungen

• Verschieben von replyChannels in die Services (siehe unten)
• Anfügen von fitConnect in die Services
• Signaturgenerierung -> DVDV hängt aktuell von replyChannels ab und NICHT von services.
• SSP anpassen -> #508

Migration der ReplyChannels

• Migration an den neuen Ort in der DB (Destination -> Destination Services)
• SSP verwaltet ReplyChannels am neuen Ort -> #508
• Bei Create/UpdateDestination (POST,PUT,PATCH) mit deprecated replyChannels
  • Sind in einer Destination unterschiedliche ReplyChannels pro Service gesetzt, so resultiert ein Update der Replychannels über das Top-Level-replyChannel-Objekt in einem Fehler (4xx).
• Zu bedenken: Bei Abruf einer Destination mit mehreren Services
  • Wenn replyChannels aller Services gleich sind
    • Herausgeben von deprecated replyChannels, da gleich
  • Wenn replyChannels unterschiedlich
    • Nichtherausgabe des deprecated replyChannels-Attributs (ist optional in der API)
    • Alternative (Wunsch/Idee Alex): Falls replyChannels in den Services unterschiedlich sind, werden solche replyChannels am alten Ort angezeigt, die in allen Service auftauchen (Konkret: Bei alles Reply Channels taucht E-Mail auf, aber die restlichen Reply Channels sind unterschiedlich).

Akzeptanzkriterien

1. Die replyChannels werden in der Datenbank mit einer Migration von der Destination in alle existierenden Services verschoben. Falls die die Destination mehrere Services hat, kommt in jeden Service eine Kopie. Using migration.
2. Die replyChannels sind an dem neuen Ort für jeden Service individuell bearbeitbar. Using migration.
3. Werden replyChannels beim Bearbeiten am alten Ort übermittelt (verhalten eines API-Clients, der das Minor Release nicht kennt), so werden sie wie bei der Migration an den neuen Ort verschoben und für alle bestehenden Services gesetzt. Using loop+setter in Destination.
4. Bei der Abfrage einer Destinaton (GET /v1/destinations/{destinationId}) wird replyChannels auch am alten Ort ausgegeben, sofern die replyChannels aller Services gleich sind
5. Bei der Abfrage einer Destinaton (GET /v1/destinations/{destinationId}) wird replyChannels auch am alten Ort nicht ausgegeben, wenn die replyChannels in den Services unterschiedlich sind --> Alternatives Akzeptanzkriterium, falls praktikabel umsetzbar: Falls replyChannels in den Services unterschiedlich sind, werden solche replyChannels am alten Ort angezeigt, die in allen Service auftauchen (Konkret: Bei alles Reply Channels taucht E-Mail auf, aber die restlichen Reply Channels sind unterschiedlich).
6. replyChannels wurde um fitConnect gemäß API-Spec ergänzt -- Das landet dann ggf. auch am alten Ort, das ist aber schemakonform.
7. Fehlercodes in API-Spec und Doku auf Vollständigkeit prüfen/korrigieren
8. NEU: Die Spezifikationen der Submission API und der Self-Service API sind angepasst. -> #508
9. NEU: Beim Export der Zustellpunkte ins DVDV werden die replyChannels wie bisher am alten Ort exportiert.
10. NEU: Sind in einer Destination unterschiedliche ReplyChannels pro Service gesetzt, so resultiert ein Update der Replychannels über das Top-Level-replyChannel-Objekt in einem Fehler (4xx).

TODO

• Metadata in 1.2.0 releasen, mit fitConnect im ReplyChannel. Steht in #460 (closed)