In einem ersten Beitrag zu Jira Workflow Properties haben wir bereits über das setzen einer Property in Transitionen berichtet. Die Status Properties (Eigenschaften von Arbeitsablaufschritten) werden in diesem Beitrag beschrieben. Diese eignen sich u.a., um Berechtigungen in bestimmten Status einzuschränken, also zum Beispiel welche User wann einen Kommentar verfassen dürfen.
Wer die Status Properties beherrscht, kann sich eventuell eine App für Jira sparen. Eine grundlegende Kenntnis lohnt sich also.
Anders als bei den Transitionen gibt es zu den Status diverse Ausprägungen der Properties selbst. Dies liegt daran, dass es sich grundlegend eigentlich nur um eine handelt, aber je Berechtigung und Gruppe, User, Rolle etc. vervielfacht.
Eine elementare Syntax für die Status Properties
Der Anwendungsbreich der Properties in Transitionen ist das Einschränken der in einem Jira Projekt durch Berechtigungsschemata (Permission Scheme) gegebenen Berechtigungen. Dies sei besonders betont, denn die Berechtigungen können nur eingeschränkt, nicht aber erweitert werden. Ist also beispielsweise bereits das Kommentieren für die Projektrolle “QA” im Schema unterbunden, kann dies nicht nachträglich über den Workflow erlaubt werden.
Bis auf wenige Ausnahmen folgt eine jede Permission Property, die gesetzt wird, der selben Syntax. Diese lautet:
jira.permission[.subtasks].{permission}.{userscope}[.suffix]- Der erste Teil “jira.permission” ist gesetzt.
- Optional kann dann auf Subtasks beschränkt werden. Wird dieser Parameter verwendet, gilt die Property nicht für den Vorgang selbst, sondern für die Unteraufgaben, solange sich der Vorgang in dem Status befindet.
- An der Stelle von {permission} steht die Berechtigung, welche man einschränken möchte. Es können beispielsweise “create”, “comment” oder “resolve” eingetragen werden.
- An der Stelle von {userscope} steht der Geltungsbereich der Einstellung, welche die Menge der Benutzer definieren kann. Zum Beispiel können “group”, um auf eine einzelne Gruppe, “userCF”, um auf User aus einem Benutzerfeld oder aber “projectrole”, um auf eine Rolle zu beschränken
- Der “Property Value” ist dann jeweils beispielsweise der Gruppenname oder die ID einer Rolle (siehe Beispiel unten).
- Wenn man eine Berechtigung mehr als einmal auf den selben Geltungsbereich einschränken möchte, muss man weiterhin ein Suffix angeben. Hierbei handelt es sich nur um eine Zahl.
- Eine vollständige Liste, der möglichen Werte für {permission} und {userscope} findet sich in der Dokumentation von Atlassian.
Status Property jira.permission.{permission}.denied
Um eine Berechtigung nicht auf einen bestimmten Geltungsbereich zu reduzieren, sondern vollständig zu unterbinden, kann anstelle von {userscope} auch “denied” angegeben werden. Wie das Wort bereits erahnen lässt, ist eine Berechtigung dann für niemanden gegeben. Das Feld “Property Value” wird bei der Angabe dann leer gelassen.
Status Property jira.issue.editable
Erwähnt sei an dieser Stelle die Property “jira.issue.editable” mit den Werten (Property Value) “true” oder “false”. Mit dieser kann ein Vorgang als editierbar einstellt werden – was ein solcher aber ohnehin zu meist ist. Oder aber das editieren unterbunden werden. Letzteres ist aber auch mit der Angabe von “jira.permission.edit.denied” erreichbar. Daher ist die Property im Grunde redundant.
Ein Beispiel zum weiteren Verständnis
In der obigen Abbildung ist exemplarisch zu sehen, wie die die Properties für eine Status in Jira hinterlegt sein könnten.
jira.permission.edit.group.1=jira-admnistrators
jira.permission.edit.group.2=qa-exception-handlers
Wenn sich ein Vorgang in diesem Status befindet, kann dieser nur noch von den Mitgliedern zweier Gruppen bearbeitet werden. Sie müssen sich entweder in der Gruppe “jira-administrators”, “qa-exception-handlers” oder aber in beiden Gruppen befinden.
jira.permission.transition.reporter=
Weiterhin kann der Vorgang den Status nur verlassen, wenn die Transition durch den Reporter (Autor) angeschoben wird. Ohne diese Person, oder aber eine Änderung des Feldes durch ein Mitglied der oben genannten Gruppen ist dies nicht möglich.
jira.permission.subtasks.transition.denied=
Die Transitionen für jegliche Unteraufgaben sind unterbunden. Diese, wenn vorhanden, stecken also alle in ihrem aktuellen Status fest, bis der übergeordnete Vorgang seinen Status verlassen hat.
jira.permission.comment.userCF=11038
Die einzigen Personen, die an dem Vorgang Kommentare hinterlassen können, sind die, die in dem Feld mit der ID 11038 ausgewählt sind. Es handelt sich hier um ein benutzerdefiniertes Feld.
Zu bemerken ist, dass manche Properties einen numerischen Wert (z.B. userCF, groupCF oder projectRole) verlangen, während andere Werte (wie bspw. user oder group) als Namen angegeben werden, und andere wiederum leer gelassen werden – wie oben bei “reporter” oder “denied” zu sehen. Wie in Teil 1 zum Thema Workflow Property – Transition Properties beschrieben, können die IDs beispielsweise beim Bearbeiten der Rollen, Felder etc. aus der URL gelesen werden.
Hier im Beitrag zu beschreiben, wie jede einzelne Eigenschaft mit ihrem Wert anzugeben ist, würde den Rahmen dieses Beitrages sprengen. Ein Probieren und Erforschen der Möglichkeiten ist empfohlen. Gerne helfen wir bei weiterführenden Fragen – hier geht es zum Kontaktformular.
