Automatisierung und Effizienzsteigerung mit Hilfe von Scriptrunner für Jira – Teil 2
In diesem Beitrag geht es weiter mit dem Überblick, wie Scriptrunner für Jira an der einen oder anderen Stelle zur Automatisierung von wiederkehrenden Vorgängen und Abläufen eingesetzt werden kann. Nachdem wir uns im ersten Teil mit JQL-Scripts, Built-In-Scripts und Behaviours beschäftigt haben, widmen wir uns heute weiteren Scriptrunner-Modulen.
Listener
Das Modul „Listener“ ist sehr mächtig und vielseitig einsetzbar. In einem früheren Beitrag haben wir euch aufgezeigt, wie ihr euren eigenen Custom Listener schreiben könnt. In diesem Beitrag wollen wir nun näher auf die im Standard mitgelieferten Listener eingehen, die viele Aufgaben für euch übernehmen können.
Erstellen eines Listeners
Zum Bereich Listener gelangt ihr, wenn ihr im Administrationsbereich unter Scriptrunner auf „Listener“ klickt:
Im rechten Bereich geht es nun weiter mit einem Klick auf „Create Listener“.
Hier findet ihr nun eine Übersicht über die möglichen Listener.
Initial werden alle Möglichkeiten angezeigt. Über die linksseitigen Piktogramme könnt ihr die Auswahl bei Bedarf thematisch eingrenzen.
Schauen wir uns nun ein Szenario an, bei dem die mitgelieferten Listener hilfreich und nützlich sein können.
Szenario
Beim Anlegen eines Vorganges vom Typ „Story“ soll automatisch ein Untervorgang vom Typ „Subtask“ erstellt werden, in dem dann später die Arbeiten erfolgen können.
Hierfür benutzen wir den Listener „Create a sub-task“. Ein Klick darauf öffnet die Konfigurationsansicht.
Hier müssen wir nun die entsprechenden Daten einpflegen:
Bezeichner
Beschreibung
Inhalt in unserem Use-Case
Note
Notiz für die Listenansicht, mit der wir den Listener leichter identifizieren können.
Automatisch Story unter Epic
Project(s)
Für welche Projekt(e) soll der Listener gültig sein.
Euer Projektname
Events
Auf welche(s) Ereignis(se) soll der Listener reagieren.
Wenn ein neuer Vorgang erstellt wird, also „Issue Created“
Condition
Unter welchen Bedingungen soll der Listener arbeiten?
Nur, wenn der erstellte Vorgang vom Typ „Story“ ist. Dies erreichen wir mit folgendem kleinen Code: issue.issueType.name == ‚Story‘
Target Issue Type
Vorgangstyp des zu erstellenden Subtasks
Subtask
Subtask Summary
Zusammenfassung des Subtasks: Wenn wir hier nichts eintragen, wird die Zusammenfassung der Story übernommen.
Leer lassen
Fields to copy
Welche Feldinhalte sollen aus der Story in den Subtask übernommen werden? Bei der Auswahl von „Custom“ können einzelne Felder definiert werden.
All
As user
Wer soll als Ersteller des Subtasks eingetragen werden? Ohne Eintrag ist es automatisch der Ersteller der Story.
Leer lassen
Additional issue actions
Hier können zusätzliche Aktionen definiert werden, die im Anschluss ausgeführt werden sollen (Statusänderungen, Feldänderungen, etc.).
Lassen wir in unserem Beispiel leer
Subtask Action
Workflow-Aktion, die mit dem neuen Subtask ausgeführt wird, wenn ein gleicher Subtask bereits im System besteht.
None
Die fertig ausgefüllte Maske sieht nun so aus:
Jobs
Jobs sind vergleichbar mit den aus Server-Umgebungen bekannten Cronjobs und dienen der zeitgesteuerten, automatisierten Abarbeitung von Aufgaben im Hintergrund, ohne dass Benutzerinteraktionen notwendig sind. Mitgeliefert wird von Scriptrunner – neben der Möglichkeit eigene Jobs anzulegen – nur eine einzige Vorlage: „Escalation service“. Da diese Vorlage jedoch einen wichtigen Bereich der Projektkontrolle abdecken kann, wollen wir ihn uns genauer ansehen.
Szenario
Alle Vorgänge vom Typ „Aufgabe“ meines Projektes, die seit 14 Tagen nicht aktualisiert worden sind, sollen in den Status „Stop Progress“ gesetzt werden, damit sie nicht mehr als „In Arbeit“ angezeigt werden.
Den Bereich „Jobs“ erreichen wir wie gewohnt über die Scriptrunner-Navigation im Administrationsbereich.
Ein Klick auf „Create Jobs“ öffnet die Ansicht der Erstellungsmöglichkeiten.
Wie schon erwähnt gibt es neben der Möglichkeit, einen eigenen „Custom scheduled Job“ zu erstellen, nur eine mitgelieferte Vorlage. Ein Klick auf „Escalation service“ öffnet die Konfigurationsmaske:
Hier müssen wir nun die für uns passenden Daten und Werte angeben.
Bezeichner
Beschreibung
Inhalt in unserem Use-Case
Note
Notiz für die Listenansicht, mit der wir den Job leichter identifizieren können.
Vernachlässigte Vorgänge
User
Welcher Benutzer soll formal die Aufgaben des Jobs ausführen?
Ein zu den Aktionen berechtigter Benutzer
Interval/ Cron expression
Das ist die „Schaltzentrale“ des Jobs. Hier wird mit Hilfe von Cron-Expressions definiert, wie oft und wann der Job ausgeführt werden soll. Über „Show examples“ werden einige Beispiele sichtbar gemacht. Für unseren Job nutzen wir eines dieser Beispiele: „Jeden Tag eine halbe Stunde nach Mitternacht“ Um mehr über Cron-Expressions zu erfahren, lege ich euch folgendes Tutorial sehr ans Herz.
0 30 0 ? * *
JQL Query
Per JQL wird hier definiert, welche Vorgänge betroffen sind. Also in unserem Fall: • Projekt = unser Projekt • Vorgangstyp = Aufgabe • Seit 14 Tagen nicht aktualisiert
project = „BLOG“ AND issuetype = „Aufgabe“ AND updated <= -14d
Action
In welchen Workflowstatus soll der Vorgang verschoben werden?
Stop Progress
Transition Options
Hier kann definiert werden, welche eventuell vorhandenen Restriktionen ignoriert werden sollen, um die definierten Aktionen auszuführen.
Alle drei Optionen aktiv
Additional issue actions
Hier können zusätzliche Aktionen definiert werden, die im Anschluss ausgeführt werden sollen (Statusänderungen, Feldänderungen, etc.).
Lassen wir in unserem Beispiel leer
Die fertig ausgefüllte Maske sieht nun so aus:
Anmerkung: Wie ihr sehen könnt, wird direkt neben dem Interval-Feld der Zeitpunkt der Ausführung und neben dem Feld mit der JQL Query die Zahl der aktuellen Treffer angezeigt – eine äußerst praktische, direkte Überprüfungsmöglichkeit.
Ein Klick auf „Add“ legt den Job an und speichert ihn im System.
Fragments
Ein weiteres, sehr hilfreiches Modul aus Scriptrunner ist das „Fragments“-Modul. Hiermit können wir direkten Einfluss auf die dem Benutzer angezeigte Oberfläche nehmen: Es ist möglich, neue Elemente hinzuzufügen, vorhandene Elemente und Masken zu verändern oder zu erweitern sowie Elemente unter genau definierten Bedingungen auszublenden. Ein Fragment stellt in diesem Kontext also immer ein Fragment der Oberfläche dar, welches individuell angepasst ist. Auch in diesem Bereich liefert Scriptrunner einige nützliche, vordefinierte Vorlagen mit, die man einfach und effektiv nutzen kann. Hierfür möchten wir euch ein Beispiel zeigen:
Szenario
Ich möchte verhindern, dass in meinem Projekt Vorgänge geklont werden können. Daher möchte ich die Möglichkeit gar nicht erst angezeigt bekommen.
Wie üblich erreichen wir die „Fragments“ über die Scriptrunner-Navigation im Administrationsbereich.
Auch hier bieten die linksseitigen Piktogramme die Möglichkeit, die Fragments nach Themengebieten einzugrenzen. Für unser Beispiel wählen wir die Option „Hide system or plugin UI element“. Wie gewohnt öffnet sich eine knappe Konfigurationsmaske zur Eingabe unserer Daten.
Bezeichner
Beschreibung
Inhalt in unserem Use-Case
Note
Notiz für die Listenansicht, mit der wir das Fragment leichter identifizieren können.
Verstecke Clonen
Hide what
Welches UI-Element soll nicht angezeigt werden? Hier ist eine Liste der Definitionen aller UI-Elemente im gesamten Jira-System hinterlegt. Achtet darauf, das/die richtige(n) Element(e) anzugeben. Eine hilfreiche Quelle für Informationen hierzu ist die offizielle Scriptrunner-Dokumentation
Bedingung(en) unter der/denen das Element ausgeblendet werden soll. In unserem Beispiel also immer im Kontext unseres Projektes.
jiraHelper.project?.key == „BLOG“
Die ausgefüllte Maske sieht nun so aus:
Wie immer legt ein Klick auf „Add“ das neue Fragment an.
Der Bereich der Fragmente ist sehr umfangreich und bietet eine Fülle von Möglichkeiten, die Benutzeroberfläche den eigenen, individuellen Arbeitsabläufen und Bedürfnissen anzupassen. Das vorige Beispiel soll aufzeigen, wie einfach es ist, individuelle Anpassungen mit Scriptrunner für Jira vorzunehmen. Natürlich sind auch wesentlich komplexere Optionen wie das Erstellen komplett eigener Schaltflächen mit Hinterlegung von Workflowlogiken jeglicher Art (auch und gerade unter Zuhilfenahme weiterer Scriptrunner-Module) machbar, aber das würde den Rahmen dieses Blogbeitrages sprengen.
Möchtet ihr mehr über Scriptrunner für Jira wissen? Interessieren euch weitere Module oder braucht ihr tiefergehende Informationen? Dann schreibt eure Fragen einfach in die Kommentare. Hinterlasst auch gerne einen Kommentar, wenn euch der Beitrag gefallen hat oder ihr andere Fragen oder Anregungen habt.
