Genehmigungs-Workflow

    In Kombination mit dem Zammad Add-on für i-doit lässt sich ein Genehmigungs-Workflow abbilden. Dafür nutzt Zammad eine Kombination aus selbst definierten Attributen, Webhooks, Makros und Trigger.

    Hier der Ablauf:
     
    1. Jemand erstellt ein Ticket, mit einem genehmigungspflichtigen Antrag.
    2. Ein Agent prüft die Anforderung, schreibt eventuell einen Artikel zur Erklärung für die Person die den Antrag genehmigen soll und setzt den Ticket Status auf "Genehmigung"
    3. Ein Trigger schreibt die User-ID des aktuellen Ticket-Eigentümers in ein benutzerdefiniertes Attribut (Kickback-User)
    4. Ein weiterer Trigger löst einen Webhook zu i-doit aus, der die Ticket-ID, einen Gruppennamen, eine Rolle und optional ein Objekttyp an die API von i‑doit übergibt.
    5. In i-doit wird innerhalb der übergebenen Gruppe nach Personen mit der übergebenen Rolle gesucht und bei einem Treffer die erste Person als neuen Ticket-Eigentümer in Zammad festlegt.
    6. Der oder die neue Ticket-Eigentümer:in schreibt in einem Artikel ob der Antrag genehmigt oder abgelehnt werden soll und löst über ein Makro die Rückgabe des Tickets an den ursprünglichen Ticket-Eigentümer (Kickback-User aus Schritt 3) aus.
    7. Ab hier kann das Ticket wie jeder andere Service Request abgearbeitet werden.

    Einrichten des Workflows

    1. Attribut für einen Kickback-User erstellen

    Zunächst wird ein Ticket Attribut vom Typ "Integer-Feld" erstellt, in das via Trigger die ID des Ticket-Eigentümers geschrieben wird. Da dieses Feld nur von Webhooks verwendet wird, muss es niemals für Anwender sichtbar sein. Die entsprechenden Checkboxen können also abgewählt werden.

    2. Ticket-Status "Genehmigung" anlegen

    Dieser zusätzliche Status wird nur verwendet um den Trigger auszulösen, der die ID des Ticket-Eigentümers in das zuvor angelegte Integer-Feld schreibt. Alternativ kann ein anderes Ticket-Attribut dafür verwendet werden.

    3. Erstellen der Webhooks 

    Für den gesamten Workflow werden drei Webhooks benötigt:

    3.1 Webhook zum schreiben der ID des aktuellen Ticket-Eigentümers in das benutzerdefinierte Attribut vom Schritt 1 (Kickback-User)

    Damit nach der Genehmigung das Ticket wieder den selben Eigentümer bekommt wie zuvor, speichern wir die ID des aktuellen Ticket-Eigentümers im zuvor erstellten benutzerdefinierten Attribut. Das erledigt ein Webhook über den Zammad ein Selbstgespräch führt. Wenn Sie dem Ticket Attribut den Namen "kickback_user" gegeben haben, sieht die Payload für den Webhook folgendermaßen aus: 
    {"kickback_user": "#{ticket.owner_id}"}

    3.2 Webhook zum Ansprechen der i‑doit API um nach der Person zu suchen, die die Genehmigung erteilen soll und diese als neuen Ticket-Eigentümer festlegt

    Für die Suche nach der Person, die die Genehmigung erteilen soll, erweitert das Zammad Add-on für i‑doit die API um den Endpunkt "zammad.owner.change.v2". Neben der aktuellen Ticket ID (nicht die Nummer) erwartet der Endpunkt den Namen eines i‑doit Objekts dessen Objekttyp die spezifische Kategorie "Personengruppen (Personengruppen)" zugewiesen hat und die Konstante einer Rolle die einem Mitglied der Gruppe zugewiesen sein soll. Optional kann ein Objekttyp für die Personengruppe angegeben werden. Wird kein Objekttyp angegeben, wird im Objekttyp "Personengruppen" nach der angegebenen Gruppe gesucht.

    Existiert die angegebene Personengruppe in i‑doit und wird ein Gruppenmitglied mit der angegebenen Rolle gefunden, wird i‑doit seinerseits die API von Zammad nutzen um den Ticket-Eigentümer auf die gefundene Person zu ändern.
     
    Wenn zum Beispiel die Abteilungen Anwender:innen in i‑doit als Personengruppen angelegt sind und dem oder der Abteilungsleiter:in die Rolle "C__MODULE__DPA_ZAMMAD__HEAD_OF_DEPARTMENT" zugewiesen worden sein, dann würde folgender Webhook den Ticket-Eigentümer entsprechend ändern:
    {
      "version": "2.0",
      "method": "zammad.owner.change.v2",
      "params": {
        "apikey": "{your-api-key}",
        "ticket_id": "#{ticket.id}",
        "group_name": "#{ticket.customer.department}",
        "role_const": "C__MODULE__DPA_ZAMMAD__HEAD_OF_DEPARTMENT",
        "obj_type": "C__OBJTYPE__PERSON_GROUP"
      },
      "id": 1}

    3.3 Webhook zum Ändern des Ticket-Eigentümers auf die im benutzerdefinierten Attribut (Kickback-User), nach erfolgter Genehmigung oder Ablehnung des Antrags

    Wenn der Antrag genehmigt oder abgelehnt wurde, soll der Eigentümer des Tickets wieder auf den ursprünglichen Eigentümer zurückgestellt werden. Dafür wird ein dritter Webhook erstellt, der die ID aus dem benutzerdefinierten Attribut "kickback_user" liest und den Eigentümer wieder auf diese ID zurückstellt. Wie schon im Schritt 3.1 führt Zammad über die API ein Selbstgespräch:
    {"owner_id": "#{ticket.kickback_user}"}

    4. Trigger und Makros

    Um die im Schritt 3 erstellten Webhooks auszulösen werden Trigger und Makros verwendet.

    Der erste Trigger wird ausgelöst, wenn ein Ticket auf den Status "Genehmigung" gestellt wird. Dieser Trigger ruft den unter 3.1 beschriebenen Webhook zum schreiben der ID des aktuellen Ticket-Eigentümers in das benutzerdefinierte Attribut "kickback_user".

    Der zweiter Trigger wird durch das Setzen des "kickback_user" Attributs ausgelöst. Der erste Trigger löst also den zweiten Trigger aus, der seinerseits den unter 3.2 beschriebenen Webhook aufruft um in i‑doit nach der Person zu suchen, die die Genehmigung erteilen soll und diese als neuen Ticket-Eigentümer festzulegen.

    Der dritte Webhook, der den Ticket-Eigentümer wieder zurück auf den ursprünglichen Eigentümer stellt, kann von einem Makro ausgeführt werden, das gleichzeitig den Ticket-Status von "Genehmigung" zurück stellt. Aber es wäre auch weitere Status wie "genehmigt" oder "abgelehnt" möglich, die, wenn sie für das Ticket eingestellt werden, den Webhook aufrufen.
    Veröffentlicht