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.
Die wichtigsten Features kurz zusammengefasst
- Dateninterpretation und -manipulation in Postfunctions
- In Groovy Scripts Zugriff auf die gesamte JIRA API
- Versenden von frei definierbaren Emails
- Ausführen von wiederkehrenden Aufgaben als Cronjobs
- Detaillierte und bedingungsabhängige Definition von Pflichtfeldern (Behaviours)
- Scripted Fields zur Darstellung kalkulierter Werte
- JQL Funktionen wie hasComments, hasAttachments, uvm.
- Kopieren von ganzen Projekten
- u.v.m
Anwendungsbeispiele
Um die Möglichkeiten zu skizzieren möchte ich hier drei Beispiele für den Einsatz des JIRA ScriptRunners geben.
Beispiel 1: Groovy Postfunctions
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.
Beispiel 2: Pflichtfelder durch Behaviours
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.
Beispiel 3: Wiederkehrende Aufgaben
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:
- Die Angabe einer einzelnen Zahl. Damit wird festgelegt, im Abstand von wie vielen Minuten der Job gestartet wird.
- Angabe einer Cron Notation zur differenzierten Steuerung der Wiederholung.
Wir entscheiden uns mit Bezug auf den Usecase für die 2. Version und schreiben als Intervall:
0 0 1 * *
