Jira Workflow Properties: Berechtigungen je Status steuern

Mit Workflow Properties legen Sie in Jira Cloud fest, wer in einem bestimmten Status kommentieren, bearbeiten oder Dateien anhängen darf. Atlassian dokumentiert die Schlüssel offiziell in der Jira-Cloud-Administration.

Ein typischer Fall: Nach „Done“ soll niemand mehr kommentieren oder Felder ändern. Das Berechtigungsschema kennt keinen Status, es gilt für den ganzen Space. Workflow Properties schränken einzelne Rechte dagegen je Status ein.

Atlassian benennt in Jira Cloud Begriffe um: Ein Work Item hieß früher Vorgang (Issue), ein Space hieß Projekt (Project). Wir verwenden die neuen Begriffe. Menüpfade nennen wir so, wie sie in der Atlassian-Dokumentation und der englischen Oberfläche heißen.

Aufbau eines jira.permission-Schlüssels

Jede Property besteht aus einem Schlüssel (Property key) und einem Wert (Property value). Für Berechtigungen gilt dieses Muster:

jira.permission.[subtasks.]{permission}.{user}[.suffix]

• subtasks. ist optional. Damit gilt die Einschränkung für die Subtasks eines Work Items.
• {permission} ist das Recht, das Sie einschränken, etwa comment oder edit.
• {user} legt fest, wer das Recht behält. Atlassian nennt applicationRole, assignee, reporter, sd.customer.portal.only, groupCF, group, lead, projectrole, user und userCF.
• .suffix ist eine optionale Zahl. Damit setzen Sie dieselbe Property mehrfach, etwa für zwei Rollen.

Der Wert hängt vom Typ ab. Bei group tragen Sie die Gruppen-ID ein, bei user die Account-ID. Bei projectrole folgt die ID der Space-Rolle (früher Projektrolle). Bei reporter bleibt der Wert leer.

Gruppennamen funktionieren nicht mehr. Atlassian hat 2023 auf Gruppen-IDs umgestellt und alte Einträge nicht automatisch übersetzt. Eine Property mit Gruppennamen gilt als nicht erfüllt, die Mitglieder verlieren das Recht.

Statt eines Typs können Sie .denied anhängen, der Wert bleibt dann leer. Diese Variante sperrt die Aktion im Status für alle, ausdrücklich auch für Admins.

Wichtig: Properties schränken nur ein, was das Berechtigungsschema erlaubt. Sie gewähren keine zusätzlichen Rechte. Wer laut Schema nicht kommentieren darf, kann es auch mit einer Property nicht.

Häufige Schlüssel und ihre Wirkung

Die Tabelle zeigt eine Auswahl für den Teil {permission}. Die vollständige Liste steht in der Atlassian-Dokumentation Use workflow properties.

Zusätzlich gibt es jira.issue.editable. Mit dem Wert false ist das Work Item im Status nicht mehr bearbeitbar. Atlassian nennt als typischen Einsatz den Endstatus eines Workflows.

Property im Workflow-Editor setzen

In company-managed Spaces dürfen laut Atlassian Site-Admins und Personen mit der Berechtigung Edit workflows für den Space Workflows ändern. Diese Berechtigung reicht nur, wenn kein anderer Space den Workflow nutzt.

1. Wählen Sie Settings (Zahnrad) > Work items > Workflows und suchen Sie den Workflow.
2. Öffnen Sie den Workflow-Editor über More actions (•••) > Edit.
3. Wählen Sie im Diagramm den Status, zum Beispiel „Done“.
4. Wählen Sie im Detailbereich das Pluszeichen neben Properties und dann + Add new property.
5. Tragen Sie Property key und Property value ein und wählen Sie Save.
6. Veröffentlichen Sie die Änderung mit Update workflow.

Die Änderung gilt sofort für alle Spaces, die diesen Workflow nutzen. Die Property gehört zum Status in genau diesem Workflow. Nutzen andere Workflows denselben Status, setzen Sie die Property dort erneut.

Auch Transitionen haben Properties, etwa jira.field.resolution.exclude für die Auswahl der Lösungen (Resolutions). Die jira.permission-Schlüssel führt Atlassian dagegen als Status-Properties.

Für team-managed Spaces beschreibt Atlassian den Weg über Space settings > Work types > Edit workflow. Ob jira.permission dort genauso wirkt, sagt die Dokumentation nicht. Unsere Beispiele beziehen sich auf company-managed Spaces mit Berechtigungsschema.

Beispiel 1: Kommentieren im Status Done sperren

Nach Abschluss soll niemand mehr kommentieren. Setzen Sie im Status „Done“ diese Property:

Property key:   jira.permission.comment.denied
Property value: (leer lassen)

Die Sperre gilt für alle, auch für Admins. Auf Transition-Screens fällt das Kommentarfeld ebenfalls weg. Vorhandene Kommentare bearbeiten oder löschen steuern Sie getrennt, etwa mit jira.permission.commenteditown.denied.

In den folgenden Beispielen schreiben wir kurz Schlüssel = Wert. Links steht der Property key, rechts der Property value.

Beispiel 2: Bearbeiten nur für eine Rolle erlauben

Im Status „In Review“ sollen nur Mitglieder der Rolle Administrators Felder ändern. Die Rolle hat hier die ID 10002, auf Ihrer Site kann sie abweichen:

jira.permission.edit.projectrole = 10002

Der Schlüssel edit regelt nur die Felder. Kommentieren, Zuweisen, Verknüpfen und Statuswechsel bleiben laut Atlassian für alle möglich, die das Recht im Schema haben. Diese Aktionen schränken Sie mit eigenen Schlüsseln ein:

jira.permission.edit.projectrole = 10002
jira.permission.assign.projectrole = 10002
jira.permission.link.projectrole = 10002
jira.permission.comment.projectrole = 10002

Für eine zweite Rolle hängen Sie eine Zahl als Suffix an:

jira.permission.edit.projectrole.1 = 10002
jira.permission.edit.projectrole.2 = 10000

Beispiel 3: Anhänge sperren

Anhänge sollen nur im Status „In Progress“ möglich sein. Atlassian empfiehlt dafür, die Sperre in allen anderen Status zu setzen:

jira.permission.attach.denied =

Das verhindert neue Anhänge. Wer vorhandene Dateien vor dem Löschen schützen will, ergänzt zwei weitere Properties:

jira.permission.attachdeleteall.denied =
jira.permission.attachdeleteown.denied =

Rollen-ID und Gruppen-ID ermitteln

Die IDs liefert die Jira-REST-API. Öffnen Sie die Adressen angemeldet im Browser und ersetzen Sie die Platzhalter. Die API verwendet dabei weiter den alten Begriff project.

https://ihre-site.atlassian.net/rest/api/3/project/SPACE-KEY/role

Die Antwort listet jede Rolle mit einer Adresse. Die Zahl am Ende ist die Rollen-ID. Sie brauchen dafür Admin-Rechte für einen Space oder für Jira. Laut Atlassian teilen sich alle Spaces einer Site dieselbe Rollenliste.

https://ihre-site.atlassian.net/rest/api/3/group/bulk?groupName=GRUPPENNAME

Das Feld groupId enthält die Gruppen-ID. Dafür brauchen Sie die globale Berechtigung Browse users and groups.

Grenzen und Test vor dem Einsatz

Atlassian weist selbst darauf hin, dass einige Properties Fehler verursachen können. Drei Grenzen sind auf jira.atlassian.com dokumentiert:

• jira.issue.editable = false verhindert nicht, dass sich jemand das Work Item zuweist. Als Umgehung nennt Atlassian jira.permission.assign.denied.
• Das Anlegen von Subtasks lässt sich per Property nicht sperren. Laut Atlassian hat Jira Cloud das nie unterstützt.
• Die Funktion Log in as user wendet jira.permission-Properties nicht verlässlich auf das gewählte Konto an. Für Tests taugt sie daher nicht.

Für den Test empfehlen wir diese Reihenfolge:

1. Legen Sie einen Test-Space mit einer Kopie des Workflows an.
2. Setzen Sie dort die Property und veröffentlichen Sie den Workflow.
3. Prüfen Sie mit einem echten Testkonto ohne Admin-Rechte, ob die Aktion gesperrt ist.
4. Prüfen Sie mit einem Konto aus der berechtigten Rolle, ob sie noch funktioniert.
5. Übernehmen Sie die Property erst danach in den produktiven Workflow.

Funktioniert nach einer Änderung etwas nicht mehr, entfernen Sie die Property wieder. So empfiehlt es auch Atlassian.

Workflows und Berechtigungen in der Schulung

Wie Berechtigungsschema, Rollen und Workflows zusammenspielen, üben Sie in unserer Schulung Jira für Projektadministratoren. Alle Formate finden Sie in der Übersicht der Jira Schulungen.

Quellen

• Use workflow properties, Atlassian Support
• Add a workflow property, Atlassian Support
• Space access and configuration permissions, Atlassian Support
• Work item permissions in a space, Atlassian Support
• Workflow property: jira.permission.edit.group not allowing the tabs to be visible on edit screen, Atlassian Knowledge Base
• RFC-6: Change in workflow properties, Group Name to GroupId, Atlassian Developer Community
• Jira Cloud REST API: Project roles und Groups, Atlassian Developer
• JRACLOUD-77632: jira.permission.edit.* property is not working as expected
• JRACLOUD-82044: Issue assignee is editable even after closed and with the property jira.issue.editable false
• JRACLOUD-26208: Subtasks can be created even when create permission is removed via Workflow state Properties
• JRACLOUD-98903: Log in as user should accurately enforce workflow step properties