3
JIRA - Sichtberkeit der benutzerdefinierten Felder rollenbezogen anpassen
Hallo,
wir habe da ein kleines JIRA-System für ein Projekt.
Die Authentifizierung erfogt via AD-Gruppen. Diesen AD-Gruppen werden JIRA-intern zu diversen Rollen wie Admin und PO hinzugefügt.
Es gibt bestimmte Felder, die nur eine bestimmte Rolle sehen soll.
Kann mir jemand sagen wie ich die "felderbezogenen" Sichtbarkeit / Berechtigungen einrichten kann?
Vielen Dank.
I.
wir habe da ein kleines JIRA-System für ein Projekt.
Die Authentifizierung erfogt via AD-Gruppen. Diesen AD-Gruppen werden JIRA-intern zu diversen Rollen wie Admin und PO hinzugefügt.
Es gibt bestimmte Felder, die nur eine bestimmte Rolle sehen soll.
Kann mir jemand sagen wie ich die "felderbezogenen" Sichtbarkeit / Berechtigungen einrichten kann?
Vielen Dank.
I.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3545378448
Url: https://administrator.de/contentid/3545378448
Printed on: April 25, 2024 at 04:04 o'clock
3 Comments
Latest comment
So erst mal gar nicht 
Du kannst über die "Vorgangssicherheit" ein Issue komplett so einrichten, dass es z.B. nur für bestimmte (AD-) Gruppen oder Projektrollen sichtbar ist. Man kann das über Workflows so weit anpassen, dass beim Setzen eines Feldes das "Sicherheitsprofil" umgeschaltet wird.
Das geht aber nur über den ganzen Vorgang.
Du kannst die Sichtbarkeit und Editierbarkeit von Feldern nur über die Sichtbarkeit in den Screens steuern. Wird das Feld nicht angezeigt, kann es auch nicht geändert werden. Die Editierbarkeit kann man nur damit erreichen, indem man einen der drei Vorgänge - Bearbeiten, Anzeigen, Erstellen - einem Screen zuweist. Wenn das Feld nur auf einem Screen auftaucht für "Anzeigen", aber nicht auf Screens für "Bearbeiten" oder "Erstellen", dann ist es quasi read-only.
Welcher Screen angezeigt wird, musst Du - wenn überhaupt - über Workflows lösen, was kompliziert werden kann.
Atlassian empfiehlt, sowas nur für komplette Vorgänge ("Vorgangssicherheit") zu lösen. Jira ist nicht für "Sicherheit auf Feldebene" gebaut worden. Ich empfehle, es auch nicht mit zusätzlichen Apps zu versuchen.
Baue am besten ein Testprojekt und tobe Dich mit den Screens (Bildschirmmasken auf Deutsch) aus bzw. den Verknüpfungen von Screens zu den Vorgängen und der Auswahl von Screens über den Workflow.
Du kannst über die "Vorgangssicherheit" ein Issue komplett so einrichten, dass es z.B. nur für bestimmte (AD-) Gruppen oder Projektrollen sichtbar ist. Man kann das über Workflows so weit anpassen, dass beim Setzen eines Feldes das "Sicherheitsprofil" umgeschaltet wird.
Das geht aber nur über den ganzen Vorgang.
Du kannst die Sichtbarkeit und Editierbarkeit von Feldern nur über die Sichtbarkeit in den Screens steuern. Wird das Feld nicht angezeigt, kann es auch nicht geändert werden. Die Editierbarkeit kann man nur damit erreichen, indem man einen der drei Vorgänge - Bearbeiten, Anzeigen, Erstellen - einem Screen zuweist. Wenn das Feld nur auf einem Screen auftaucht für "Anzeigen", aber nicht auf Screens für "Bearbeiten" oder "Erstellen", dann ist es quasi read-only.
Welcher Screen angezeigt wird, musst Du - wenn überhaupt - über Workflows lösen, was kompliziert werden kann.
Atlassian empfiehlt, sowas nur für komplette Vorgänge ("Vorgangssicherheit") zu lösen. Jira ist nicht für "Sicherheit auf Feldebene" gebaut worden. Ich empfehle, es auch nicht mit zusätzlichen Apps zu versuchen.
Baue am besten ein Testprojekt und tobe Dich mit den Screens (Bildschirmmasken auf Deutsch) aus bzw. den Verknüpfungen von Screens zu den Vorgängen und der Auswahl von Screens über den Workflow.
Vielen Dank Yoppi1 ...
Ich werde mir mal die einzelnen Schritte anschauen.
So weit ich sehe soll es einen Field Security Plugin für Jira geben. Ich habe dies zumindest als Empfehlung bekommen.
Es soll ziemlich genau das umsetzen was wir brauchen.
LG
I.
Ich werde mir mal die einzelnen Schritte anschauen.
So weit ich sehe soll es einen Field Security Plugin für Jira geben. Ich habe dies zumindest als Empfehlung bekommen.
Es soll ziemlich genau das umsetzen was wir brauchen.
LG
I.
Aus Erfahrung lehne ich die zusätzlichen Apps ab.
Was für ein Jira benutzt Du? Cloud, Server oder Data Center?
- Server wird nicht mehr unterstützt. Du wirst wahrscheinlich diese App über den Marketplace nicht mehr kaufen können (wenn, dann nur direkt vom Hersteller).
- Data Center geht ab 500 User los.
- Cloud kann nur eine Frickel-Lösung sein, weil die Eingriffsmöglichkeiten von Apps eingeschränkt ist. Meist werden wesentliche Funktionen ausgelagert, d.h. Daten fliessen von der Atlassian Cloud auf Server der App-Hersteller. Bei "sicherheitsrelevanten" Dingen kann dann der "Sicherheitsmechanismus" ausgehebelt werden, wenn man die Daten statt über die Weboberfläche über die REST API abfragt.
Die in Jira eingebaute Vorgangssicherheit hält sich sowohl über die Webseite als auch die REST API an Deine Vorgaben. Vorgänge, die ein User nicht sehen soll, tauchen in keiner Form nirgends auf.
Da einmal installierte Apps immer irgendwelche Rückstände hinterlassen, egal ob Cloud oder on-premise, empfehle ich Dir, mit einer Testinstanz zu arbeiten.
On-premise ist ein zweiter Server schnell aufgebaut, die Lizenz dazu kannst Du unter MAC (my.atlassian.com) abrufen - jede aktiv gewartete on-premise-Lizenz hat eine sog. "Developer-Lizenz". Die kannst Du dafür nehmen.
Für die Cloud empfehle ich, einfach eine neue Instanz mit einem zufälligen Namen einzurichten. Je nach Produkt hat man mindestens 7 Tage zum Rumspielen und kann auch die Apps ausprobieren. Wenn man keine Kreditkarten-Daten hinterlegt, wird die Instanz abgeschaltet (natürlich bekommt man von Atlassian haufenweise Erinnerungen, dass man seine Zahlungsinfos hinterlegen soll) und nach ca. 30 Tagen endgültig gelöscht. Oder man löscht die Produkte halt selber.
Probiere NIE Apps oder auch neue Produkte von Atlassian mit einem produktiven Cloud-Account aus. Probiere NIE Apps auf produktiven on-premise-Instanzen aus. Wenn Du Glück hast, bleibt nur "Datenbankdreck" zurück, den Du in alle Ewigkeit mit sichern musst. Wenn Du Pech hast, macht Dir die App die Instanz strubbelig oder fügt z.B. 50 neue Felder und 20 neue Issue Types hinzu, die Du mühsam entfernen müsstest.
Wenn Du eine on-premises-Instanz zum Testen klonen willst, musst Du das Backup&Restore selber vornehmen. Du musst Die Datenbank sichern und dann die Installation (unter /opt/atlassian/jira per Default) sowie die Daten (/var/atlassian/application-data/jira) sichern. Wenn Du das Backup aus Jira heraus machst, dann werden die Attachments nicht gesichert (sowie weitere Dateien, z.B. das Logo).
Bei Klonen daran denken, dass Du bei denen erst einmal das Mail-Handlung komplett ausschaltest, sonst saugt Dir der Jira-Klon eventuell noch nicht abgerufene Mails ab oder schickt 1000 Mailbenachrichtigungen raus. Also sofort alles, was mit "Mail" zu tun hat, in Jira ausschalten.
Jira gibt's auch als Docker-Container. Damit kann man sich auch austoben.
Was für ein Jira benutzt Du? Cloud, Server oder Data Center?
- Server wird nicht mehr unterstützt. Du wirst wahrscheinlich diese App über den Marketplace nicht mehr kaufen können (wenn, dann nur direkt vom Hersteller).
- Data Center geht ab 500 User los.
- Cloud kann nur eine Frickel-Lösung sein, weil die Eingriffsmöglichkeiten von Apps eingeschränkt ist. Meist werden wesentliche Funktionen ausgelagert, d.h. Daten fliessen von der Atlassian Cloud auf Server der App-Hersteller. Bei "sicherheitsrelevanten" Dingen kann dann der "Sicherheitsmechanismus" ausgehebelt werden, wenn man die Daten statt über die Weboberfläche über die REST API abfragt.
Die in Jira eingebaute Vorgangssicherheit hält sich sowohl über die Webseite als auch die REST API an Deine Vorgaben. Vorgänge, die ein User nicht sehen soll, tauchen in keiner Form nirgends auf.
Da einmal installierte Apps immer irgendwelche Rückstände hinterlassen, egal ob Cloud oder on-premise, empfehle ich Dir, mit einer Testinstanz zu arbeiten.
On-premise ist ein zweiter Server schnell aufgebaut, die Lizenz dazu kannst Du unter MAC (my.atlassian.com) abrufen - jede aktiv gewartete on-premise-Lizenz hat eine sog. "Developer-Lizenz". Die kannst Du dafür nehmen.
Für die Cloud empfehle ich, einfach eine neue Instanz mit einem zufälligen Namen einzurichten. Je nach Produkt hat man mindestens 7 Tage zum Rumspielen und kann auch die Apps ausprobieren. Wenn man keine Kreditkarten-Daten hinterlegt, wird die Instanz abgeschaltet (natürlich bekommt man von Atlassian haufenweise Erinnerungen, dass man seine Zahlungsinfos hinterlegen soll) und nach ca. 30 Tagen endgültig gelöscht. Oder man löscht die Produkte halt selber.
Probiere NIE Apps oder auch neue Produkte von Atlassian mit einem produktiven Cloud-Account aus. Probiere NIE Apps auf produktiven on-premise-Instanzen aus. Wenn Du Glück hast, bleibt nur "Datenbankdreck" zurück, den Du in alle Ewigkeit mit sichern musst. Wenn Du Pech hast, macht Dir die App die Instanz strubbelig oder fügt z.B. 50 neue Felder und 20 neue Issue Types hinzu, die Du mühsam entfernen müsstest.
Wenn Du eine on-premises-Instanz zum Testen klonen willst, musst Du das Backup&Restore selber vornehmen. Du musst Die Datenbank sichern und dann die Installation (unter /opt/atlassian/jira per Default) sowie die Daten (/var/atlassian/application-data/jira) sichern. Wenn Du das Backup aus Jira heraus machst, dann werden die Attachments nicht gesichert (sowie weitere Dateien, z.B. das Logo).
Bei Klonen daran denken, dass Du bei denen erst einmal das Mail-Handlung komplett ausschaltest, sonst saugt Dir der Jira-Klon eventuell noch nicht abgerufene Mails ab oder schickt 1000 Mailbenachrichtigungen raus. Also sofort alles, was mit "Mail" zu tun hat, in Jira ausschalten.
Jira gibt's auch als Docker-Container. Damit kann man sich auch austoben.
