“… Können wir die Storys nur für die Entwickler sichtbar machen? … “ oder “… die Kollegen aus der Fachabteilung sollen nur Tasks erstellen können …” sind Fragen oder Aufgabenstellenungen, die uns in unserer täglichen Arbeit in der Betreuung von Jira oft gestellt werden.

Jetzt hat Jira zwar ein ausgeklügeltes Berechtigungssystem mit hoher struktureller Tiefe, aber bei solchen Anfragen kommen oft auch erfahrene Jira-Admins an die Grenzen der Konfigurationsmöglichkeiten. Doch Jira bietet eine eher selten genutzte Funktionalität, auf die wir heute schauen wollen: “Issue Security” oder “Vorgangssicherheit”.

Oftmals wird bei der Einrichtung von neuen Projekten die Vorgangssicherheit nicht konfiguriert. Das liegt wahrscheinlich an zwei Dingen:

Das Setup von der Vorgangssicherheit ist in den Template-Projekten nicht enthalten und muss mindestens initial von Hand aufgebaut werden.

Mit Vorgangssicherheit bekommt man effektiv eine zusätzliche Stufe im Berechtigungssystem von Jira, welches häufig schon im Basissetup für Unklarheiten bei Usern führt.

Dabei ist diese Funktionalität sehr mächtig und kann (insofern richtig konfiguriert) einige komplexe Use-Cases abdecken, die anderweitig nicht möglich wären. Daher haben wir 5 dieser Beispiele zusammengetragen, um sie hier vorzustellen:

1. Veraltete Inhalte archivieren, ohne Statistiken zu verfälschen

Das Archivieren von Vorgängen ist ein Feature von Jira auf Data Center. Mit der Einrichtung einer Vorgangssicherheit können Projekt-Administratoren (oder jede andere gewünschte Rolle, Gruppe oder User) einfach im Vorgang festlegen, ob dieser “archiviert” werden soll, und damit eine Archivierung von einzelnen Vorgängen auch auf Server oder Cloud Instanzen nachahmen.

Dabei wird der Vorgang vor den normalen Usern versteckt. Admin-User können die Vorgänge weiterhin sehen. Damit werden auch Auswertungen für die Admin-User nicht verfälscht, während normale User weniger Inhalte sehen, die bereits irrelevant sind.

Die Funktion, einzelne Vorgänge “echt” zu archivieren, ist bisher nur Data Center Installationen vorbehalten. Dabei müssen aber weitere Nebeneffekte beachtet werden:

Best practices for issue archiving with Jira

2. Inhalte vor externen Benutzern verstecken

Zwar ist es durchaus möglich, ganze Projekte für eine Gruppe von Usern freizugeben oder eben zu verstecken. Häufig gibt es jedoch auch den Wunsch, nur einzelne Inhalte eines Projektes für eine Gruppe von Usern zu verstecken.

Beispielsweise könnten in einem Projekt neue Stories nur für interne Mitarbeiter sichtbar sein, während externe Mitarbeiter weiterhin Bugs und Tasks sehen können.

3. An IT-Sicherheitsthemen arbeiten, ohne diese öffentlich zugänglich zu machen

Wenn die gesamte IT in Jira arbeitet und dort ihre Aufgaben dokumentiert, warum dann nicht auch das Team der IT-Security? Das Problem dabei ist, dass das Team die Unterstützung von anderen Teams benötigt, gleichzeitig sollen aber die IT-Security Themen nicht einfach für alle Mitarbeitenden der Organisation lesbar sein.

Für diesen Fall könnte die Vorgangssicherheit so konfiguriert werden, dass nur solche User entsprechende Vorgänge sehen können, die explizit von einem Admin in einem Feld eingetragen wurden.

4. Auswertungen für Entwickler ohne Business-Aufgaben

Insbesondere in agilen Setup sind cross-funktionale Teams immer wichtiger. Oftmals kann es bei Auswertungen dann aber zu Verwirrungen kommen, wenn beispielsweise alle Entwicklungsaufgaben rechtzeitig erfüllt worden sind, es aber noch offene Business-Aufgaben gibt. In diesen Fällen können die Ziele oder die KPI's also nicht erreicht werden.

Über die Konfiguration der Vorgangssicherheit könnten Business-Aufgaben für Entwickler unsichtbar gemacht werden. Dabei würden solche Aufgaben auch in Auswertungen oder Listen nicht mehr sichtbar.

5. Sichtbarkeit von Aufträgen nur für bestimmte Lokationen

Wie bereits in unserem früheren Blog (Prozessoptimierung in der Disposition) beschrieben, können auch Lieferaufträge zentral in einem Projekt verwaltet werden, ohne dass einzelne Aufträge über die Grenzen des jeweiligen Standorts hinweg sichtbar sind.

Prozessoptimierung in der Disposition

So kann ein zentrales Team alle Aufträge in einem Projekt sehen und bearbeiten, während User von dedizierten Standorten nur jene Aufträge sehen können, die auch ihnen bzw. ihrem Standort zugewiesen sind.

Sicher gibt es noch jede Menge anderer oder ähnlicher Anwendungsfälle für Vorgangssicherheit. Die genannten Beispiele zeigen hoffentlich, was es für Möglichkeiten gibt, die Vorteile eines gemeinsamen Jira-Projektes nutzen zu können, ohne den einzelnen User mit einer möglichen Flut an Inhalten zu überfordern.

Um die bestmöglichen Ergebnisse zu erzielen und den Anforderungen von Teams in Jira gerecht zu werden, sollte die Vorgangssicherheit nicht übersehen werden, sondern als zusätzliches Tool dem Werkzeugkasten eines Jira-Administrators zur Verfügung stehen.

Je nach Komplexität der Vorgangssicherheit kann ein durchdachtes Rollenkonzept hilfreich sein oder mindestens unterstützend wirken. Aufgrund der Flexibilität der Konfiguration (nach Rollen, Gruppen oder Usern) ist es aber nicht zwingend notwendig.

Wir bei Swarmit haben diese und andere, ähnliche Setups bereits mehrfach bei verschiedenen Kunden in den produktiven Einsatz gebracht und können gerne bei der Konzeption und Umsetzung von Vorgangssicherheit bei Jira-Projekten unterstützen.

‍