SSP-2.1.0: React-Komponente zum Erstellen von API-Clients Part I
Warum?
Die Client-Verwaltung soll auch via React umgesetzt werden. In diesem Zuge soll auch das UI neu gestaltet werden.
Als ein Verfahrensbetreiber/Entwickler:in,
möchte ich bei der Anlage von neuen Clients dabei unterstützt werden, mich zwischen Sender und Subscriber zu entscheiden und direkt die konkreten Zustellpunkte (im Falle von Subscriber-Clients) auswählen können.
Relevante Links und Bemerkungen
Akzeptanzkriterien
-
Auf der Seite Client anlegen wird beschrieben, warum einen Client angelegt werden muss (inkl. Verweis auf docs). -
Clients sind entweder Sender- oder Subscriber-Clients. Dies wird durch einen entsprechenden Dialog abgefragt ("Möchten Sie einen Sender oder einen Subscriber-Client anlegen?", inkl. Erklärtext). -
Subscriber-Clients können 0..n Zustellpunkte zugeordnet werden ( immer mind. 1 - Hintergrund: Clients müssen mindesten einen Scope zugeordnet haben, siehe FCONSD-184). Wenn keine Zustellpunkte ausgewählt werden, wird eine ensprechende Warnung angezeigt, dass der Subscriber-Client keine Submissions empfangen können wird. -
Unter der Auswahl der Zustellpunkte existiert ein Hinweis mit Link auf die Zustellpunktverwaltung. Ergänzung: Wenn kein Zustellpunkt erstellt wurde wird ein Hinweis erstellt mit der Verlinkung auf Create Zustellpunkt. -
Für Sender-Clients besteht keine Möglichkeit, Zustellpunkte zuzuordnen (siehe #262 (closed)). -
Für Subscriber-Clients kann ausgewählt werden, ob subscribe:
-Scopes ("API-Client für den Abruf von Submissions berechtigen") und/odermanage:
-Scopes ("API-Client für die Konfiguration von Zustellpunkten berechtigen") vergeben werden sollen. Die Auswahl kann pro API-Client getroffen werden und gilt dann für alle zugewiesenen Zustellpunkte des Subscriber-Clients. Die Auswahl beeinflusst die Zuweisung von OAuth-Scopes durch den OAuth-Server.- -> Prüfen beim PO-Review, ob es hier Nebenwirkungen der Self-Service-API gibt. --> Wird mit SSP-API eingeführt bis dahin ist dieser Teil ausgeblendet. Ist das ok @Alexander_Hoose, @Marco_Holz ?
- Anmerkung Marco: Die Unterscheidung zw. Subscriber- und Mange-Scopes hat nichts mit der SSP-API zu tun. Das Feature kann bei Bedarf dennoch gerne in eigenen Issue ausgelagert werden. In diesem Fall bitte hier durchstreichen und neues Issue verlinken.
-
Die Checkbox zur Autorisierung auf die Self-Service-API aus #581 (closed) bleibt erhalten. --> kann nicht bearbeitet werden, weil es keine SSP-API gibt. Daher müsste mit der vorherigen Aufgabe ausgegliedert werden in ein neues Ticket. --> ist in #541 (closed) -
Bei der Auswahl von Zustellpunkten werden der vom User vergebene Name des Zustellpunktes, dessen Destination-ID, alle im Zustellpunkt hinterlegten Regionen (ohne Dopplungen) und alle im Zustellpunkt hinterlegten Leistungsschlüssel angezeigt. -
Der Dialog zum Erstellen von Clients kann jederzeit abgebrochen und neugestartet werden. -
Nach Abschluss des Erstellens eines API-Client werden Client-ID und Client Secret einmalig angezeigt. -
Es wird ein Hinweis angezeigt, dass das Client Secret nur einmalig angezeigt wird und später nicht mehr eingesehen werden kann. --> Widerspricht dem nächsten Punkt. @Marco_Holz, @Alexander_Hoose was soll hier gemacht? -> Anmerkung Marco: Das Client-Secret soll nur per "Click-to-Copy" kopiert werden können, während es einmalig angezeigt wird. -
Client-ID und Client-Secret können per "Click-to-Copy" einfach per Mausklick kopiert werden (vgl. #683 (closed)). -
NEU: Auch in der Detail-Ansicht des API-Clients (in der Übersicht) wird der Hinweis angezeigt, dass das Secret nur einmalig angezeigt wird und dass ein neuer API-Client erzeugt werden muss, wenn das Secret verloren gegangen ist.
-
-
Das Client-Secret wird nicht im SSP gespeichert. -
Abgesehen von den hier beschriebenen Abweichungen verhält sich die Client-Verwaltung identisch zur bisherigen Implementierung im SSP. -
Die React-Komponente ist ins SSP integriert.
Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)
-
Aufgrund des Bugs (https://git.fitko.de/fit-connect/planning/-/issues/1222) wurde ein Teil des Tickets schon gemerged, der noch offene Teil des Issues wird in #1232 (closed) bearbeitet. -
... -
... -
Definition of Done wurde geprüft
Edited by Laura Elges