Der JIRA ScriptRunner ist ein Plugin, welches JIRA um Workflow Post-Functions, Listener und Services erweitert.
Das Plugin bietet verschiedene Einstiegspunkte um JIRA mit Hilfe von Groovy Scripten um kleine Funktionen bequem zu erweitern, ohne direkt ein eigenes Plugin entwickeln zu müssen.
Im vorliegenden Artikel möchte ich anhand von drei kleinen Beispielen kurz einige wesentlichen Features des ScriptRunner erläutern.
Der ScriptRunner for JIRA ist ein Plugin der Firma Adaptavist aus München.
Er ist ein mächtiges Werkzeug zur schnellen und flexiblen Umsetzung von speziellen Anforderungen und erweitert unter Anderem die Möglichkeiten von JIRA Postfunctions in Workflows erheblich.
Darüber hinaus bietet er noch andere vielfältige Eingriffsmöglichkeiten und ist eine leichtgewichtige Alternative zur aufwändigen Entwicklung eigener Plugins.
Der JIRA ScriptRunner kommt mit einer großen Auswahl von fertigen Modulen und bietet darüber hinaus noch sehr weitreichende Möglichkeiten durch den Einsatz von eigenen Groovy Scripten.
Das ehemals eigenständige Plugin Behaviours ist (seit JIRA 6.4) Teil des ScriptRunners und ermöglicht es das Verhalten von Custom- und Systemfields differenziert zu beeinflussen.
Um die Möglichkeiten zu skizzieren möchte ich hier drei Beispiele für den Einsatz des JIRA ScriptRunners geben.
Usecase: Wir wollen einen bestimmten User automatisch als Beobachter für jedes neue Ticket registrieren.
Dazu definieren wir eine eigene Postfunction in einer Workflow Transition.
Der ScriptRunner bietet uns in der Liste der bekannten Postfunctions den neuen Punkt Script Postfunctions an.
Unter diesem Punkt finden wir eine Liste von vordefinierten Funktionen.
Wir wählen hier den Punkt Custom script post-function aus, um ein eigenes Groovy Script auszuführen.
Hier können wir entweder ein Script aus dem Dateisystem des Servers referenzieren oder einfach und schnell ein Inline Script schreiben.
Im Feld Inline script schreiben wir unseren Groovy code:
import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.user.util.UserManager import com.atlassian.jira.user.ApplicationUser def user = ComponentAccessor.getUserManager().getUserByName('hans.mueller') def watcherManager = ComponentAccessor.getWatcherManager() watcherManager.startWatching(user, issue)
In den ersten drei Zeilen importieren wir die nötigen Klassen. Der ComponentAccessor gibt mit einer Reihe von statischen Methoden Zugriff auf diverse Manager Klassen.
Weiterhin benötigen wir den UserManager und die Klasse ApplicationUser für unser Script.
Über den ComponentManager greifen wir zu auf die Klasse UserManager und holen uns über den Namen des Users ein Objekt vom Typ ApplicationUser.
Anschließend liefert uns der ComponentManager über eine weitere statische Methode ein Objekt vom Typ WatcherManager.
Die Methode startWatching(user, issue) erlaubt uns, den User als Beobachter für das aktuelle Ticket (issue) zu registrieren.
Das Objekt issue vom Typ MutableIssue steht in der Postfunction bereits vordefiniert zur Verfügung.
Mit JIRA Bordmitteln kann ich ein Pflichtfeld nur pauschal in einer Feldkonfiguration definieren. Das hat zur Folge, dass dieses Feld dann schon im Create screen als Pflichtfeld auftaucht.
Usecase: Das standard Kommentarfeld soll nur in einer einzigen Transition als Pflichtfeld definiert sein.
Das ist möglich, mit Hilfe von Behaviours. Felder können damit auf sehr differenzierte Weise validiert werden.
Im Administrationsbereich finden wir unter Addons den Punkt Behaviours. Dort werden aktive Definitionen gelistet.
Neue Behaviors können mit Add Behaviour angelegt werden.
Wir erzeugen eine neue Behaviour und wählen unter Add Field das betreffenden Feld aus.
Dann erzeugen wir mit Add one eine neue Condition, die wir unter Workflow Action auf einen einzigen Übergang einschränken.
Danach können wir das referenzierte Feld über den Link Require als Pflichtfeld definieren.
Usecase: Am 1. jeden Monats soll das Ticket mit der ID ED-13 automatisch dupliziert werden.
Im Administrationsbereich finden wir unter Addons den Punkt Build-in Scripts. Darunter finden wir den Punkt Escalation Service.
Dort werden bestehende Services gelistet. Unter New Service kann ein neuer Service angelegt werden.
Zugriff auf Tickets bekommen wir durch einen JQL call, also z.B. id = ED-13 für ein bestimmtes Ticket.
Weiterhin müssen ein ausführender User, das Intervall und eine auszuführende Workflow Transition definiert werden.
Für die Angabe des Intervalls gibt es zwei Möglichkeiten:
Wir entscheiden uns mit Bezug auf den Usecase für die 2. Version und schreiben als Intervall:
0 0 1 * *
Wir setzen dieses Plugin in fast allen unseren Kundenprojekten ein und ich möchte es auch in zukünftigen Projekten nicht mehr missen.
Diese drei Beispiele geben einen kurzen Einblick in die Möglichkeiten, die der ScriptRunner bietet und kratzen selbstverständlich nur an der Oberfläche des Funktionsumfangs.
Wer sich intensiv mit dem Plugin und seinen Features beschäftigen möchte, der findet in der folgenden Linkliste detaillierte Informationen.
Bei Rückfragen oder zum weiteren Erfahrungsaustausch freue ich mich über eine Kontaktaufnahme!
Vereinbaren Sie einfach einen Beratungstermin mit uns. Gerne präsentieren wir Ihnen den Funktionsumfang von Atlassian JIRA in einer Live-Demo.
Unser kompetentes und erfahrenes Team von (Java-)Entwickler ist stark in Beratung, technischer Konzeption und zuverlässiger Umsetzung komplexer Projekte. In unseren Reihen haben wir Spezialisten für unterschiedliche Themengebiete, die hier ihr Fachwissen zum Besten geben.
empulse GmbH
Frankenwerft 5
50667 Köln