Eines der wesentlichen Merkmale einer Vorgangsverwaltung ist deren Rechteverwaltung. Wie wird sichergestellt, dass jeder Benutzer nur das sieht, was er sehen darf? Können Benutzer in Gruppen und Rollen eingeteilt werden? Wie granular können Berechtigungen vergeben werden?
Das in Jira umgesetzte Rechtekonzept besteht aus mehreren Komponenten, die stark voneinander abhängig sind und daher stets gemeinsam betrachtet werden sollten:
- Globale Berechtigungen,
- Berechtigungsschemas,
- Workflowberechtigungen und
- Sicherheitsschemas.
Globale Berechtigungen
Globale Berechtigungen gelten projektübergreifend in der gesamten Jira-Instanz. Durch sie wird unter anderem festgelegt, welche Benutzer und Benutzergruppen Administratorenrechte besitzen, wer Filter und Dashboards freigeben oder Mehrfachänderungen an Vorgängen durchführen darf.
Die wichtigste globale Berechtigung ist Jira-Benutzer (Jira Users). Alle Mitglieder der hier eingetragenen Nutzergruppen haben die Berechtigung, sich in Jira einzuloggen. Anders gesagt: Benutzer, die sich nicht in mindestens einer der in Jira-Benutzer eingetragenen Gruppen befinden (oder Administratoren sind), können sich nicht in das System einloggen.
Die Berechtigung Jira-Administrator legt fest, welche Nutzer „allgemeine“ Jira-Administratoren sein sollen. Alle hier eingetragenen Nutzer können sich in Jira einloggen (auch ohne Zugehörigkeit zu einer Gruppe in Jira-Benutzer). Jira-Administratoren können Schemas, Masken, Berechtigungen etc. erstellen und bearbeiten sowie diese Schemas in Projekten zuweisen. Dieser Punkt sorgt oft für Verwirrung: die Berechtigung „Projekte verwalten“ im Berechtigungsschema eines Projektes erlaubt nicht, diesem Projekt Schemas zuzuweisen – das können nur die hier beschriebenen globalen Jira-Administratoren.
Jira-Administratoren haben allerdings keinen Vollzugriff auf die Systemadministration, diesen haben nur die Nutzer mit der Berechtigung Jira-Systemadministratoren (siehe Liste der Funktionen, die nur für Systemadmins verfügbar sind).
Auch für die Jira-Lizenz sind die globalen Berechtigungen relevant: in die Lizenz zählen alle Nutzer, die sich in einer der globalen Gruppen (Jira-Benutzer, Jira-Administratoren, Jira-Systemadministratoren) befinden und nicht deaktiviert sind.
Berechtigungsschemas
Im Gegensatz zu globalen Berechtigungen beziehen sich Berechtigungsschemas auf jeweils ein- oder mehrere konkrete Projekte und definieren, welche Benutzer über welche Rechte in diesen Projekten verfügen. Dazu zählen unter anderem das Erstellen, Kommentieren und Löschen von Vorgängen. Die Sichtbarkeit eines Projektes wird durch die Berechtigung Projekte durchsuchen (Browse Projects) festgelegt. Nutzer, die hier nicht eingetragen sind, sehen weder das Projekt noch einen der darin enthaltenen Vorgänge – auch nicht auf dem globalen Dashboard oder über den Vorgangsnavigator.
Projektberechtigungen können sowohl an konkrete Personen, als auch an Benutzergruppen, Projektrollen und vorgangsspezifische Nutzer (Ersteller, Bearbeiter, Personen in benutzerdefinierten Feldern) vergeben werden. Ich persönlich empfehle, statt einzelner Nutzer oder Nutzergruppen Projektrollen zu verwenden.
Bei der Arbeit mit Berechtigungsschemas ist es wichtig, sich über den Unterschied zwischen Projektberechtigungen und Workflowberechtigungen im Klaren zu sein. Erstere beziehen sich ausschließlich auf nicht-workflowspezifische Berechtigungen – auch wenn die Bezeichnungen Vorgänge lösen (Resolve Issues) und Vorgänge schließen (Close Issues) anderes vermuten lassen. Dennoch: die Berechtigungen an Workflowübergängen werden im Workflow selbst definiert.
Workflowberechtigungen
Die Übergänge zwischen Workflowstatus können in Jira mit Bedingungen (Conditions) versehen werden. Nur wenn die für einem Übergang festgelegten Bedingungen erfüllt sind, kann der Vorgang in den zugehörigen Zielstatus überführt werden. Als Bedingungen stehen unter anderem Projektberechtigungen und Projektrollen des aktuellen Nutzers sowie der Status der Unteraufgaben des Vorgangs zur Auswahl.
Durch die Definition von Workflowberechtigungen wird es z.B. möglich, dass Vorgänge nur nach Erledigung aller Unteraufgaben in einen Status Review überführt werden und nur die Mitglieder der Projektrolle Quality Review den Vorgang daraufhin endgültig schließen können.
Sicherheitsschemas
Innerhalb eines Projektes kann es notwendig sein, die Sichtbarkeit einzelner Vorgänge auf bestimmten Nutzerkreise einzuschränken. Jira setzt diese Anforderung durch Sicherheitsschemas um. Innerhalb eines Sicherheitsschemas werden Sicherheitsstufen definiert und mit einzelnen Nutzern, Benutzergruppen oder Projekt- bzw. Vorgangsrollen verknüpft. Vorgänge, für die eine Sicherheitsstufe ausgewählt wurde, sind ausschließlich für die mit dieser Stufe verknüpften Nutzerkreise sichtbar.
Im einfachsten Fall kann hier z.B. eine Sicherheitsstufe Admins angelegt und die Benutzergruppe jira-administrators zugeordnet werden. Alle Vorgänge, für die diese Sicherheitsstufe ausgewählt wird, sind ausschließlich für Mitglieder der Gruppe jira-administrators sichtbar.
Beim Erstellen eines Sicherheitsschemas sollte eine Standardstufe festgelegt werden, die alle neu erstellte Vorgänge automatisch erhalten sollen. Das ist besonders dann wichtig, wenn nicht alle Projektmitglieder die Berechtigung zum Auswählen einer Sicherheitsstufe besitzen oder die entsprechenden Felder über die Feldkonfiguration ausgeblendet wurden.
Einschränkungen
Die Sichtbarkeit einzelner Felder eines Vorgangs kann mit Standardmitteln nicht auf bestimmte Nutzergruppen eingeschränkt werden. Trotz zahlreicher Bemühungen hat sich Atlassian endgültig dafür entschieden, diese Funktion auch in Zukunft nicht in Jira zu integrieren. Für einige spezielle Szenarien steht jedoch ein Workaround sowie ein kommerzielles Plugin zur Verfügung.
Fazit
Jiras Rechtekonzept ist mächtig und bietet ausreichend Flexibilität für verschiedenste Szenarien. Gleichzeitig benötigt es ein hohes Maß an Einarbeitung sowie gute Planung. Einige, scheinbar unkritische Einstellungen können sich ohne das richtige gewusst wie zu Fehlerquellen entwickeln – z.B. kann es ohne eine standardmäßige Sicherheitsstufe leicht passieren, dass Vorgänge versehentlich für alle Nutzer sichtbar gemacht werden.
Auch der Umstand, dass Nutzer ausschließlich Rechte erhalten, aber Berechtigungen nicht entzogen werden können, z.B. um 95 von 100 Mitgliedern einer Benutzergruppe eine bestimmte Berechtigung zuzuweisen, machen Expertenwissen, sorgfältige Planung und Schulungen unverzichtbar.
Hallo Sebastian,
ich nutze die Unteraufgaben in einem Vorgang, Problem ist dass ein zugewiesender Bearbeiter diese Unteraufgaben nicht schließen kann ? Warum ? Gibt es dafür eine versteckte Berechtigung ? Ich habe keinen Punkt gefunden
nachtrag, wie ich gerade sehe liegt es nicht an den Berechtigungen sondern bei einen Bearbeiter eines Vorgangs liegt eine andere Anordnung der Buttons für Vorgang schließen usw. vor. Ich als Admin habe diese nebeneinander bei bearbeiter erscheinen diese erst wenn Arbeitsablauf angeklickt wird.
Gibt es dafür einen Grund oder eine Einstellung ?
Hallo Daniel,
die Arbeitsablauf-Buttons zeigen die aktuell verfügbaren Statusübergänge an – dabei sieht jeder Nutzer aber nur die Buttons mit den Übergängen, die er durchführen darf. Wenn ein Vorgang z.B. gerade im Status „Offen“ ist und eingestellt wurde, dass nur der aktuelle Bearbeiter den Vorgang in den Status „Zum Test“ überführen darf, dann sieht auch nur der aktuelle Bearbeiter den Button „Zum Test“, alle anderen sehen den Button nicht. Deswegen ist die Reihenfolge der Buttons ggf. von Nutzer zu Nutzer unterschiedlich.
Prinzipiell ist es so, dass immer die ersten 3 verfügbaren Statusübergänge als Buttons dargestellt werden. Sollten mehr als 3 Übergänge möglich sein, werden die restlichen Übergänge im Aufklappmenü „Arbeitsablauf“ untergebracht.
Hoffe, das hilft dir weiter, ansonsten schreib einfach nochmal.
Grüße,
Sebastian
Hallo Sebastian,
ja die Antwort reicht mir, somit kann ich ja festlegen wie du schon gesagt hast wer welchen Vorgang starten kann und bis wohin.
Danke
Moin Sebastian.
Ich suche bereits einige Zeit in unserer Testumgebung aber auch im Netz und der Atlassin Dokumentation, ob es möglich ist einen User nur auf ein explizites Ticket sehen zu lassen und ggf. in ihm zu Arbeiten?
Über Rolle, Sicherheitsstufe etc. habe ich schon unterschiedlichste Szenarien probiert, erlange jedoch auf diese Weise letztendlich doch wieder Zugriff auf Tickets, die auch andere User sehen können.
Die Hoffnung keimte zwischendurch einmal auf, als ich die für uns neue Funktion „Benutzer einladen“ in der JIRA 6.2 (derzeit noch bei uns in der Testumgebung) fand. Ich hoffte, dass dies ihn explizit zum Ansehen nur dieses einen Vorgangs berechtigen könnte. Tatsächlich wird er jedoch wirklich nur eingeladen, sich den Vorgang anzusehen, was ohne bereits vorhandene Berechtigungen nicht möglich ist.
Hast Du eine Idee, wo, ob und ggf. mit welchem AddOn so etwas lösbar ist?
vg Thomas
Hallo Thomas,
ich denke ich hätte da noch eine Idee: zunächst müsstest du für das entsprechende Projekt ein eigenes Berechtigungsschema erstellen. Die Berechtigung „Projekte durchsuchen“ richtest du per Gruppen/Rollenzuordnung so ein, dass der entsprechende Nutzer das Projekt nicht sehen kann. Dann weist du der Berechtigung „Projekte durchsuchen“ auch „Aktueller Bearbeiter“ zu. Das hat zur Folge: ab dann sehen alle Nutzer das Projekt, auch wenn sie eigtl. keine Berechtigung dazu haben – sie sehen aber erstmal keine Vorgänge in dem Projekt. Erst, wenn man als Bearbeiter eines Vorgangs eingetragen wird, sieht man genau diesen einen Vorgang in dem Projekt. Wird man als Bearbeiter entfernt, sieht man auch den Vorgang nicht mehr.
Das gleiche wird bei Support-Projekten häufig mit dem Feld „Autor“ gemacht, dann können alle Nutzer das Projekt sehen, sehen darin aber nur die Vorgänge, die sie selber erstellt haben (bzw. wo sie im Feld „Autor“ eingetragen sind).
Statt dem aktuellen Bearbeiter könntest du natürlich auch ein eigenes benutzerdefiniertes Feld vom Typ „Benutzerauswahl“ verwenden. Vorgehen wäre das gleiche, einfach dieses Feld im Berechtigungsschema bei „Projekte durchsuchen“ per Einstellung „Wert des benutzerdefinierten Benutzerfelds“ eintragen. Wer dann in diesem Feld ausgewählt ist, kann genau diesen Vorgang sehen. Mit dem benutzerdefinierten Feld könntest du dann auch noch weiter arbeiten, z.B. indem du noch weitere Berechtigungen erteilst oder im Workflow definierst, dass der Nutzer in diesem Feld bestimmte Schritte im Workflow durchführen darf.
Als Info: für alle Nutzer, die ganz normal per Gruppen/Rollenzuordnung die Berechtigung haben, dieses Projekt zu sehen, bleibt alles wie gewohnt, d.h. diese Nutzer sehen auch weiterhin wie gewohnt alle Vorgänge in diesem Projekt.
Hoffe, das hilft dir weiter!
Grüße,
Sebastian
Hi Sebastian.
That does it !
Mit diesem guten Hinweis ist für uns eine neue Vielfalt an Reglementierungsmöglichkeiten sichtbar geworden, derer wir uns zuvor nicht bedienten.
In Kombination mit dem Bedingungen, die sich an Workflow-Übergänge knüpfen lassen, haben wir jetzt den gewünschten Zustand erzielen können: Usern können Einzeltickets zum „nur gucken“ zugewiesen werden.
Genauso können wir jetzt auch – das wurde bereits intern früher einmal angefragt – Tickets nur den zugewiesenen Bearbeitern sichtbar machen.
Danke, für den guten Tipp und die nachvollziehbare Schilderung, mit der wir uns die „Bereiche“ von JIRA erschließen konnten!
vg Thomas
Hallo Sebastian,
deine Aussage zur JIRA Lizenz ist nicht mehr ganz korrekt.
Richtig muss es lauten, dass die Anzahl der Nutzer aus den globalen Gruppen (JIRA System Administrators, JIRA Administrators, JIRA Users) abzüglich aller inaktiven Nutzer für die Lizenz relevant sind.
siehe https://confluence.atlassian.com/display/JIRAKB/How+to+Get+a+List+of+Active+Users+Counting+Towards+the+JIRA+License
vg Detlef
Hi Detlef,
stimmt, meine Aussage war nicht mehr aktuell – ich habs geändert, Danke!
Grüße,
Sebastian
Hallo Sebastian,
ist es möglich Userrechte so zu „stricken“, dass User nur bestimmte (selbst erstellte) Issues zugreifen bzw. diese sehen können? (Alternativ nur auf bestimmte Issue-Typs?)
Vielen Dank für deine Hilfe im Voraus!
Hallo Angelo,
ja das geht: jedes Projekt besitzt ja ein Berechtigungsschema. Wenn du im entsprechenden Berechtigungsschema der Berechtigung „Projekt durchsuchen“ (diese steuert, wer das Projekt und die enthaltenen Vorgänge sehen darf) die Einstellung „Autor“ hinzufügst, hat das zur Folge: jeder kann das Projekt sehen, sieht darin aber nur die Vorgänge, in denen er selbst als Autor eingetragen ist. Das wird z.B. in Supportprojekten häufig so gemacht.
Zusätzlich zum „Autor“ kannst du natürlich auch noch beliebige andere Rollen oder Gruppen in die Berechtigung „Projekt durchsuchen“ eintragen, diese sehen dann das Projekt und die Vorgänge ganz normal, also alle Vorgänge im Projekt. Nur wer keine durch Rollen-/oder Gruppenzugehörigkeit erhaltene Leseberechtigung für das Projekt besitzt, sieht mit der Autor-Einstellung trotzdem das Projekt und darin eben nur die selbst erstellten Vorgänge.
Alternativ kannst du auch ein Sicherheitsschema für das Projekt einrichten. Mit dem Sicherheitsschema kannst du verschiedene Sicherheitsstufen definieren, diese jeweils mit Rollen/Gruppen verknüpfen, und dann jedem Vorgang in dem Projekt eine Sicherheitsstufe zuweisen. Dann sehen nur noch die Rollen/Gruppen, die in der entsprechenden Sicherheitsstufe eingetragen sind, den Vorgang.
Grüße,
Sebastian
Hallo Sebastian,
ich habe folgende Frage: In einem aktuellen JIRA board soll der letzte Schritt von „In Review“ zu „Done“ nur von einer eingeschränkten Zahl an Usern durchführbar sein. Kannst du mir dazu einen Tipp geben, ist das möglich? (Ich bin JIRA beginner :-))
Danke vorab!
Grüße
Gabriele
Hallo,
ja, das ist möglich: man kann für jeden Statusübergang in einem Arbeitsablauf festlegen, wer diesen Übergang durchführen darf. Dafür bearbeitet man den Arbeitsablauf und fügt beim entsprechenden Statusübergang die Bedingung „Nutzer in Projektrolle“ (oder „Aktueller Bearbeiter“ oder „Gruppe“ o.ä., je nachdem wer den Übergang durchführen darf) hinzu. Das ganze habe ich in der FAQ zu Workflows kurz mit beschrieben, damit sollte es klappen.
Grüße,
Sebastian
Hallo Sebastian,
ich versuche 1 Projekt in 3 Gruppe zu teilen und jede von dieser Gruppe darf nur sein Ticket anschauen. Kann ich durch Berechtigungsschema diese Konstellation durchführen?Hast Du eine Idee?
Schöne Grüße
Julio
Hallo Julio,
ja das geht, allerdings nicht mit den Berechtigungsschemas, sondern mit einem zusätzlichen Sicherheitsschema (siehe mein Artikel zu Sicherheitsschemas). In einem Sicherheitsschema kannst du verschiedene Sicherheitsstufen festlegen und jeder dieser Stufen bestimmte Gruppen oder Projektrollen zuordnen. Wenn du in einem Projekt dieses Sicherheitsschema aktivierst, kannst du für jeden Vorgang in diesem Projekt eine der vorher definierten Sicherheitsstufe festlegen. Ein Vorgang ist dann nur noch für diejenigen Nutzer sichtbar, die sich in einer der Gruppen/Rollen seiner Sicherheitsstufe befinden. In deinem Fall könntest du also 3 Sicherheitsstufen anlegen und dort jeweils eine deiner 3 Gruppen zuweisen.
Wichtig wäre noch, dass du im Berechtigungsschema des Projektes in der Berechtigung „Vorgangssicherheit festlegen“ („Set Issue Security“) alle Nutzer einträgst, die in diesem Projekt die Sicherheitsstufe der Vorgänge festlegen können. Gleichzeitig musst du noch darauf auchten, dass in der Erstellen/Bearbeiten Bildschirmmaske dieses Projekttest das Feld „Sicherheitsstufe“ drin ist, sonst kann man die Sicherheitsstufe nicht auswählen.
Grüße,
Sebastian
Hallo Sebastian,
danke für Deine ausführlichen Artikel zu Jira und die ausführliche Beantwortung der Leserfragen. Diese waren mir bei dem Verständnis von Jira sehr hilfreich.
Mit unserem System sollen drei unterschiedliche Gruppen arbeiten: GU (Generalunternehmer), Subunternehmer und der Kunde.
Gibt es eine Möglichkeit die Sichtbarkeit von Kommentaren in einem Vorgang so zu beschränken, dass der Sub Kommentare nur für seine Projektrolle veröffentlichen kann – und nicht für alle?
Es gibt die Möglichkeit Kommentare für die jeweils zugeordnete Projektrolle(n) oder allen Nutzern sichtbar zu machen.
Zusammenfassend: Ich möchte Rollenspezifisch konfigurieren inwieweit Nutzer die Privatsphäre von Kommentaren in Vorgängen einstellen können.
Danke und Grüße
Adrian
Hallo Adrian,
sorry für die späte Antwort – sofern deine Frage noch aktuell ist: die von dir beschriebene Funktionalität ist eigentlich standardmäßig schon enthalten. Beim Kommentieren kann man den Kommentar immer nur auf diejenigen Projektrollen beschränken, denen man selbst angehört. Wenn ich z.B. in der Rolle „Developer“ bin, aber nicht in der Rolle „Administrators“, dann bekomme ich bei der Auswahl der Sichtbarkeit nur die Developer-Rolle angezeigt.
Selber konfigurieren kann man das ganze als Admin allerdings nicht, man kann also z.B. nicht festlegen, dass die Developer die Sichtbarkeit eines Kommentars auch auf Administrators beschränken können – macht auch Sinn, sonst könnte man sich selber aussperren.
Grüße,
Sebastian
Guten Tag Herr Höhne,
ist es möglich 3 Sicherheitsstufen auszuwählen oder innerhalb von einer Sicherheitsstufe 2 Gruppen und den Aktuellen Bearbeiter festzulegen?
In einem momentanen Projekt sollen 2 Gruppen alle Tickets sehen und der aktive Bearbeiter nur während seinen Arbeitsstatus. Ist das möglich?
Mir ist bewusst das ich die Sicherheitsstufe während eines Überganges ändern lassen kann, aber ohne Doppel- bzw. Dreifachbelegung ist dies auch nicht hilfreich.
Über eine Antwort würde ich mich freuen und wäre Ihnen sehr Dankbar!
Mit freundlichen Grüßen
Max Schnabel
Hallo Herr Schnabel,
das ist kein Problem – Sie können jeder Sicherheitsstufe mehrere Gruppen/Rollen/Personen zuweisen. Jeder Nutzer, der sich in einer entsprechenden Gruppe/Rolle usw. befindet, kann den Vorgang sehen. Eine beispielhafte Konfiguration sehen Sie z.B. hier unter „Screenshot 2: the ‚Edit Issue Security Levels‘ page“. Ihre vorgeschlagene Konfiguration ist sogar relativ üblich: alle Vorgänge erhalten eine Sicherheitsstufe, darin soll eine bestimmte Gruppe von Nutzern alle Vorgänge dieser Stufe sehen, und alle restlichen Nutzer sollen nur diejenigen Vorgänge sehen, in denen sie als Bearbeiter eingetragen sind. Einziges Manko: wenn man gerade Bearbeiter ist und den Vorgang einem anderen Nutzer zuweist, dann „verschwindet“ der Vorgang für einen selbst. Dessen muss man sich dann einfach nur beweusst sein, das ist ja gewünschte Funktionalität.
Beste Grüße,
Sebastian Höhne
Hallo Sebastian,
vielen Dank für Deine Antwort bzgl. der Anordnung der benutzerdefinierten Felder.
Ich hätte noch eine Frage zu den Berechtigungen: Kann ich das Bearbeiten (Datum ändern) von Start und End Dates auf eine bestimmte Rolle einschränken? Wir arbeiten mit BigPicture und möchten nicht, dass jeder User die Termine verschieben kann.
Hast Du hierzu einen Tipp?
Vielen Dank schon mal!
Herzliche Grüße
Martina