Zammad: Dateianhang

[darenegade]

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

Als Prozessberater möchte ich die Zammadintegration auch dafür nutzen können, um Dateien einem Artikel hinzufügen zu können, um z.B. Bescheide zustellen zu können.

Describe the solution you'd like

• Einbindung S3 in Zammadintegration
  • inkl. Custom S3
• Übergabe Liste von Dateien/Pfaden (Analog DMS Schriftstücke)
• Offen: Wie sieht es mit Datei-Limits aus?
  • Limit von Zammad-EAI -> Klärung mit Zammad-Team -> Umstellung auf MultiPart möglich @darenegade
  • Limit der eigenen EAI -> Ziel: Einfache Zwischenlösung für viele große Dateien (z.B. Limit 50MB) einbauen, wenn einfach möglich -> Wenn es keine einfache Lösung gibt, dann wird das Thema hier ausgegrenzt
• Anpassung Showcase und Templates
• Doku (Integration & Modellierung)

Describe alternatives you've considered

Acceptance Criteria

• Es lassen sich Dateien aus dem Prozess an ein Zammad Ticket hochladen
• Das Feature ist dokumentiert

Additional context

[darenegade]

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

[lmoesle]

@darenegade Wie handhaben wir in der ticket-integration Lese- und Schreibrechte von Dateien im S3 Storage? So wie ich's verstehe werden dem Integrationsaufruf Dateipfade übergeben und die Integration lädt die Dateien herunter. Theoretisch kann ein Prozessentwickler einen beliebigen Pfad im S3 angeben. Müssen wir hier Leserechte umsetzen?

[darenegade]

@lmoesle Eigentlich sollte das analog zu der DMS Integration sein. Demnach gehe ich davon aus, dass dort das Problem auch besteht. Dann würde ich das hier erstmal ausgrenzen und in einem neuen Ticket angehen

[lmoesle]

Bei DMS wird der Filecontext mit übergeben und dann in dem gesucht. Aber der Filecontext wird im bpmn Prozess gesetzt und kann dementsprechend einfach manipuliert werden.

[darenegade]

Ja, dass ist nicht optimal, aber man muss auch erstmal den Filecontext kennen. Für das Problem haben wir ja: https://app.zenhub.com/workspaces/digiwf-621f70bf50ea1100120b7e93/issues/gh/it-at-m/digiwf-core/983

[lmoesle]

@darenegade Welche File types sollen für den Upload nach Zammad unterstützt werden?

[darenegade]

@lmoesle Aktuell gibt es bei Zammad keine Einschränkungen, daher würde ich es aktuell nicht auf gewisse Typen einschränken.

[lmoesle]

FYI Der Zammad Client und der S3 Client (die Service Accounts) sind ja später aus unterschiedlichen Realms. Den Usecase hatten wir mit der digiwf-security lib bisher noch nicht. Das Security Setup in der Zammad Integration müssen wir nochmal anpassen.

[darenegade]

Der Zammad Client und der S3 Client (die Service Accounts) sind ja später aus unterschiedlichen Realms

Also nur in Bezug auf unsere Umgebungen (Dev/Test), bei den anderen sollte es gleich sein

Den Usecase hatten wir mit der digiwf-security lib bisher noch nicht.

Den Use-Case an sich haben wir aber schon bei CoSys. Dort wird dann einfach ausgehend eine eigene OAuth-Config genutzt.

Grundsätzlich sehe ich die digiwf-security Lib eher für Vereinfachung für DigiWF interne Kommunikation. Nach außen müssen wir immer flexibel und wahrscheinlich auch individuell bleiben.

Können wir gerne im Daily nochmal drüber sprechen

[lmoesle]

Offene Punkte

• Ticket für die fehlenden Funktionen im S3Adapter in der DMS Integration erstellt DMS Integration supports domain specific S3 storages #1441
• Der S3Adapter ist sehr ähnlich zum S3Adapter in der DMS Integration. Ich habe ein Ticket angelegt, um den Adapter in eine eigene Bibliothek zu verschieben: Move duplicate s3 logic to client libs #1442
• Deployment der Zammad Integration Init Zammad Integration Ops #1377
  • Ich habe bisher gegen den OpenAPI Contract entwickelt und konnte die Integration noch nicht gegen Zammad Testen
• Die offenen Punkte / Abstimmungen mit dem Zammad Team sind noch offen
  • Datei Limits von der Zammad EAI und von der Integration
  • Abstimmungen wegen der Zammad API Anpassungen