Custom DMS-Input (simple)

[darenegade]

Is your feature request related to a problem? Please describe.

Als Sachbearbeiter*in möchte ich Schriftstücke aus dem DMS auswählen können, um diese im Prozess weiter zu verarbeiten, sodass diese an andere Systeme über den S3 verschickt werden können (Mail, anderes DMS, Druckstrasse, ...)

Der Use-Case hat noch nicht viele User, daher muss es nicht gleich die 100% Lösung sein. Wichtig ist eine gute Schnittstelle zwischen Input-Daten und Prozess. Wie der Input dann weiter mit UX-Fähigkeiten erweitert wird, kann man dann flexibel steuern.

Describe the solution you'd like

Es wird ein neuer Custom-Input benötigt, der:

• Eingabe COO-Link eines Schriftstückes
• Input prüft die Korrektheit des Links, indem es den Dateinamen abruft (Metadaten)
  • Wenn ja, dann übernimmt der Input die COO und zeigt den Dateinamen an
  • Es wird der Typ des Links validiert
  • Technisch:
    • Gateway-Route direkt auf einen REST-Endpunkt der DMS-Int.
    • Damit braucht DMS-Int. auch die SSO Sec.
    • Es wird nur mit der COO gearbeitet (Input strippt Link)
• Einträge lassen sich einzelnen entfernen
  • Bitte mit X statt Papierkorb
• Einträge verlinken auf den DMS-Link
  • Link kommt über Meta-Daten
• Input kann man DMS-Typ konfiguriert werden, sodass es für KVR oder MUCS-DMS funktioniert
  • Kompletten Link speichern hat das Problem, dass sich die Basis-URL ändern kann und dann alle Links nicht mehr gehen
  • DMS-Typ(MUCS, KVR, DIPA...) wird im Formularinput vom Form-Designer gesetzt
  • Über Metadaten Abruf auf der Integration wird der UI-Link bestimmt
• Doku des neuen Inputs
• Für lokale Tests muss der DMS Mock-Service erweitert werden
• In DMS Showcase einbauen

Describe alternatives you've considered

Eingabe der COO in ein reguläres Text-Input-Feld -> Schlechte UX und eventuell vertippt sich der User, sodass schnell Fehler auftreten

Acceptance Criteria

• [x] Es existiert ein DMS Input, der in der CoCreation einem Formular hinzugefügt werden kann
• [x] Der Input stellt sicher, dass nur valide Schriftstücke eingegeben werden
• [x] Der Input stellt den Typ des COO Objektes sicher und der Typ kann beim Input konfiguriert werden
• [x] Der Input kann vorbelegt werden und besitzt einen readonly mode
• [x] Der Input ist dokumentiert
• [x] Es existiert ein Beispielprozess mit dem Input für Tests
• [x] Feld hat ein Validierung: Required mit mindestens einem Element und die Maximale Anzahl kann auch definiert werden

Additional context

• Wird benötigt für die Umstellung des Asyl-Workflows

• https://git.muenchen.de/digitalisierung/digiwf-support/-/issues/351 (Beispiel Ticket zu dem Thema)

• https://git.muenchen.de/digitalisierung/digiwf-support/-/issues/326

• https://git.muenchen.de/digitalisierung/digiwf-support/-/issues/424

[darenegade]

Das Thema ist für die Asyl-Prozess Umstellung relevant

[darenegade]

Hier muss nochmal eine Runde über die User gedreht werden, da der (gewünschte) Flow aus UX Sicht noch unklar ist. Ich möchte vermeiden, dass wir "einfach" den alten Input nachbauen

[dominikhorn93]

[darenegade]

Hey team! Please add your planning poker estimate with Zenhub @darenegade @dominikhorn93 @lehju @lmoesle @markostreich @simonhir @StephanStrehlerCGI

[darenegade]

@dominikhorn93 Das mit dem Bild hat irgendwie nicht geklappt

[darenegade]

@lehju Wenn du das Ticket umsetzt. Ich habe gerade noch die Info bekommen, dass wir hier eventuell auf den Typ validieren müssen und es gut wäre, wenn man das beim Input festlegen könnte.

Einerseits, dass man bei Schriftstücken auch wirklich nur diese eingibt und nicht Akten-COOs oder so. Und andererseits, dass man mit dem Input auch andere Arten von Objekte der EAkte auflisten könnte.

Ich schreib das oben mal rein

[darenegade]

Wieder eröffnet, da die API des Inputs nicht dem entspricht, was hier abgestimmt war

https://git.muenchen.de/digitalisierung/digiwf-support/-/issues/424