Skip to content

Erstellung einer Oberfläche für Event-Log-Abruf von Nutzenden

Nach Implementierung von Destination-API und #2089 (closed)

User Story

Als Owner möchte ich einen Event-Log für alle Submissions abrufen können, um mich der Versendung von Submissions zu vergewissern.

Warum

Falls Submissions von einem Onlinedienst, Fachverfahren oder einer Behörde versendet wurden und diese jedoch nicht beim Empfänger angekommen sind, möchte ich dies in einem Event-Log angezeigt bekommen.

Damit im Besonderen Fachverfahren und Behörden überprüfen können, ob ein Eingang bei FIT-Connect erfolgt ist, benötigen sie eine Oberfläche, um die SubmissionID zur Überprüfung einzugeben.

Die Oberfläche sollte die SubmissionID aufnehmen und darunter die Eventlogs ausgeben, mit einem abschließenden Kommentar: "Antrag bei FIT-Connect eingegangen" oder "Kein Antrag bei FIT-Connect eingegangen".

Links, Hinweise, Bemerkungen

Acceptance criteria

  1. [ ]

    Es gibt drei Parteien, die vollen Zugriff auf das abgerufenen Event-Log haben:

    • Der Onlinedienst, der den Case mit der ersten Submission geöffnet hat
    • Das Verwaltungssystem, an das der Case/die Submission gerichtet ist
    • Der Support

    diese können im SSP eine Submission-ID oder Reply-ID (immer die vollständige UUID) eingeben und erhält Informationen zur Einreichung.

    • Geht von der Submission-ID aus, von der Destination und Client zum Owner abgeglichen werden

  2. Die Informationen zur Einreichung umfassen

    1. Ziel (Destination-ID)
    2. Verwaltungsleistung (Name & URI) aus dem Endpunkt Submission API | FIT-Connect (fitko.de)
    3. Anzahl der Attachments aus dem Endpunkt Submission API | FIT-Connect (fitko.de)
    4. Liste der Events aus dem Event Log
      1. Event (z.B. "Einreichung angelegt (submit-submission)"
      2. Zeitstempel
      3. Bei Bedarf vollständiges SET (z.B. zum aufklappen)

  3. Die Liste der Einreichungen deckt auch einen gewissen Bereich in die Vergangenheit (Vorschlag: 30 Tage) ab. D.h. auch akzeptierte, zurückgewiesene und gelöschte Einreichung stehen in der Liste

  4. ...

Mockup

grafik Der Teil "X Ereignisse gefunden" mit Zusatzinformationen zu den einzelnen Events soll nur für berechtigte Nutzer ausgegeben werden. Der Status ist für jeden angemeldeten Nutzer abrufbar.

Implementation plan (to be completed by the developer)

Followup

  1. BiDiKo Testsätze abwarten von Nutzenden und entsprechende Darstellung überarbeiten
  2. Mehrere Submissions werden dargestellt
Veraltete Informationen:

Acceptance criteria

  1. Jeder eingeloggte Nutzer (Rollen: Owner, User, Supportteam = Stakeholder: Onlinedienst, Fachverfahren, Support) kann im SSP eine Submission-ID oder Reply-ID(immer die vollständige UUID) eingeben und erhält Informationen zur Einreichung.
    • Geht von der Submission-ID aus von der destination und client zum Owner abgeglichen wird
  2. Die Informationen zur Einreichung umfassen
    1. Ziel (Destination-ID)
    2. Verwaltungsleistung (Name & URI)
    3. Anzahl und Größe der Anlagen
    4. Liste der Events aus dem Event Log
      1. Event (z.B. "Einreichung angelegt (submit-submission)"
      2. Zeitstempel
      3. Bei Bedarf vollständiges SET (z.B. zum aufklappen)
  3. Zu den vorhandenen Zustellpunkten kann eine Liste der gespeicherten Einreichungen abgerufen werden (wird in #396 bearbeitet)
  4. Die Einreichungen des Zustellpunktes sind mit den Informationen von AK 2 verlinkt
  5. Die Liste der Einreichungen deckt auch einen gewissen Bereich in die Vergangenheit (Vorschlag: 30 Tage) ab. D.h. auch akzeptierte, zurückgewiesene und gelöschte Einreichung stehen in der Liste
  6. ...

Optionen mit ZSD besprechen

  1. User für Support-Scope zum lesen des Event-Logs. Wir filtern und lesen den Event-Log.
  2. Ausgewählt: Status von Submission+Reply wird über Endpunkt abgerufen. Neuer Endpunkt muss erstellt werden. (Gewünschte Option) --> offeneren Event-Endpunkt gestalten
  3. Querry-API

Optionen Berechtigung

Überlegung zu den Berechtigungen:Es gibt drei Parteien, die vollen Zugriff auf das Event-Log haben:

  • Der Onlinedienst, der den Case mit der ersten Submission geöffnet hat
  • Das Verwaltungssystem, an das der Case/die Submission gerichtet ist
  • Der Support

Es gibt aber möglichweise Fälle, in denen andere Personen, die keinen Zugriff auf das Event-Log haben, wissen müssen, ob eine Submission abgesendet wurde. Daher sollte überlegt werden, ob jede eingeloggte Person im SSP nach Eingabe einer Submission-ID sieht, ob diese existiert und in welchem Status sie ist:

  • noch nicht abgesendet (incomplete)
  • abgesendet (submitted oder forwarded)
  • empfangen (accepted)
  • zurückgewiesen (rejected)

Alles was für Submssions möglich ist, sollte auch für Replys möglich sein.Kleiner Nachteil dieser Lösung: Wir werden dafür vermultich zwei neue public Endpunkte benötigen:

  • GET /v1/submissions/{submissionId}/status
  • GET /v1/replies/{replyId}/status

Alternativ holt sich das SSP das ganze Event-Log und extrahiert im SSP-Backend den Status.

Edited by Laura Elges