Ausgangslage der JSM Genehmigungs-Workflow-Änderung
Beispiel: Ein Unternehmen hat einen bestimmten Workflow in Jira Service Management, der vor der Statusänderung des Tickets die Genehmigung von vier Personen erfordert. Nur, wenn alle vier Personen zustimmen, kann die Bearbeitung des JSM Tickets beginnen.
Das Bild zeigt den Workflow, den unser Projekt verwendet:
Dieses Bild visualisiert, dass alle vier Personen mit Genehmigungsfunktion zustimmen müssen.
In unserem Unternehmen werden jetzt die Einstellungen des Genehmigungs-Workflows geändert: Nun soll nur noch die Genehmigung von einer Person notwendig sein, um den Status zu wechseln. Der Ticketstatus wird jetzt also geändert, sobald einer der vier Personen (egal, ob 1, 2, 3 oder 4) das Ticket genehmigt.
Hier sehen Sie die neue Konfiguration:
Problem
In Jira Service Management haben wir auch offene Tickets, die vor der Workflow-Änderung erstellt wurden. Obwohl wir den Workflow aktualisiert haben und die Tickets mit dem neuen Workflow verbunden sind, müssen wir manuell nachbessern, um die offenen Tickets im Wartezustand mit den neuen Einstellungen zu synchronisieren.
Denn obwohl bei allen, auch bei älteren, Tickets nun „1 approval needed” steht, sind die Einstellungen bei offenen Tickets faktisch noch die alten.
Lösung
Nein, eine einfache Lösung mit Bulk Changes gibt hier leider nicht, da man nicht für jedes Ticket die gleiche genehmigende Person hat.
An dieser Stelle möchten wir eine bahnbrechende Lösung mit Ihnen teilen, die unsere Actonic Consultants eigenständig erarbeitet haben.
So geht’s:
Schritt 1: Als Erstes stellen wir sicher, dass auch die alten Tickets den gleichen Workflow verwenden, um auszuschließen, dass der Fehler am Workflow liegt. Das tun wir, indem wir im Ticket beim Status auf „View Workflow” klicken.
Dann können wir den Workflow einsehen.
Schritt 2: Anschließend öffnen wir eines der alten Tickets im offenen Wartezustand, das mit der neuen Konfiguration aktualisiert werden muss. Wir exportieren dieses Ticket in das XML-Format, um die Issue-Type ID zu finden.
Wir benötigen die Issue-Type ID von jedem nicht funktionierenden Ticket. Diese erkennen wir während unseres Testprozesses.
Schritt 3: Wir öffnen das heruntergeladene File mit einem beliebigen Texteditor und kopieren uns die Issue-Type ID und speichern sie ab, denn wir benötigen sie später.
Diesen Schritt wiederholen wir für sämtliche betroffene Issue-Types.
Schritt 4: Dann verwenden wir eine Postgres Client App, um die JSM Datenbank zu öffnen. In unserem Beispiel benutzen wir die App „Beekeeper Studio“ für Mac. Es ist eine Freeware, die uns erlaubt, in der Datenbank Dinge zu bearbeiten.
Schritt 5: Jetzt wählen wir die Datenbank, welche mit unserem Jira Service Management verbunden ist. Als nächstens wählen wir den public Ordner und dann den approval Ordner, hier also die Tabelle „AO_56464C_APPROVAL“.
Höchste Zeit für ein Backup: Bitte denken Sie daran, dass Sie ein Backup der Datenbank machen, bevor Sie irgendwelche Änderungen vornehmen.
Schritt 6: Im Genehmigungs-Ordner finden wir die Ausgabe-IDs, die wir benötigen. Denn wir suchen nicht nach den Tickets, sondern nach den Issue-Type IDs, die wir schon recherchiert und abgespeichert haben.
Diese Herangehensweise mit den Issue-Type IDs ist die schnellste Art, an unser Ziel zu kommen. Würden wir die einzelnen Tickets ändern wollen, würde das viel mehr Ressourcen beanspruchen. Sie können vielleicht eine Million Tickets haben, aber so viele Issue-Type IDs haben Sie in Ihrem Unternehmen für ein einzelnes Projekt bestimmt nicht.
In unserem Fall haben wir die IDs 11000, 11001 und 11002 herausgefunden.
Der Clou kommt jetzt: Für diese IDs ändern wir „APPROVE_CONDITION_TYPE“ von „Prozent“ auf „Zahl“. Außerdem ändern wir „APPROVE_CONDITION_VALUE“ von „100“ auf „1″.
Schritt 7: Anschließend speichern wir die vorgenommenen Änderungen und gehen zu unserer Verwaltung in Jira Service Management. Hier öffnen wir eine neue Browser-Registerkarte und melden uns als „Genehmigender A“ an. In unserem Fall ist diese eine der Personen, die ein Ticket genehmigen kann.
Jetzt können wir ein altes Ticket öffnen und prüfen, ob unsere Datenbank-Änderung funktioniert hat.
Wir klicken auf „Genehmigen“ und sehen, dass der Ticketstatus auf „Warten auf Support“ geändert wurde und nur eine Genehmigung vorliegt.
Die Änderung des Workflows wurde also auch auf die offenen Tickets übertragen.
Problem gelöst.
Fazit
Wenn man das Problem von neuen Einstellungen hat, die auf Genehmigungs-Workflows in JSM angewendet werden sollen, gibt es keine Bulk Change Lösung. Bittet man den Atlassian Support um Hilfe, erhält man die Antwort, dass man die Datenbank bearbeiten soll. Wie genau, wird nicht verraten. Aber die Datenbank ist sehr empfindlich und ohne Anleitung oder absolutes Expertenwissen sollte man hier keine Änderungen vornehmen.
Deswegen haben wir diese einmalige Lösung entwickelt, bei der Sie den Konditionstyp der Genehmigung von Prozent auf Zahl ändern.
Mit unserem Ansatz im Actonic-Style kommen Sie am schnellsten und sichersten an Ihr Ziel und passen alte Jira Service Management offene Tickets im Wartezustand effizient an den neuen Genehmigungs-Workflow an.
Mehr Informationen gewünscht? Vereinbaren Sie einfach eine kostenfreie Beratungssitzung mit unseren erfahrenen Consultants. Wir beraten Sie gerne!
