Archiv der Kategorie: Jira

Jira Beobachter (engl. Watcher) in Vorgangssicherheit, Berechtigungen, usw. verwenden

Wer von einem E-Mail-basierten Ticketsystem (z.B. OTRS) auf Jira umsteigt, wird darüber stolpern, dass Jira die „CC-Funktionalität“ nicht out-of-the-box unterstützt. Konkret stellt man sich die Frage: Wie kann man in Jira abbilden, dass der vom Kunden per E-Mail geschickte Arbeitsauftrag (in Jira Vorgang genannt) nur von den Bearbeitern und von „erwünschten“ Kollegen eingesehen werden kann. Bei E-Mails nimmt man diese Kollegen ja einfach ins CC: Jeder dieser Kollegen kann die E-Mail weiteren Kollegen zu Gesicht bringen, indem er diese bei einer Antwort zusätzlich ins CC nimmt.

Grundsätzlich kann in Jira niemand ein Ticket einsehen, wenn er nicht in Projekteinstellungen -> Berechtigungen -> Projekte durchsuchen eingetragen ist. Das entspricht dem Verhalten einer E-Mail, denn vereinfacht gesagt, kann niemand eine E-Mail einsehen, wenn er nicht im CC steht.

Doch wie bildet man nun die CC-Funktionalität in Jira ab, also dass jeder, der das Ticket einsehen darf, weitere Kollegen die Einsicht in dieses Ticket erlauben darf? Die naheliegenden Felder Beobachter (engl. Watcher) im klassischen Jira oder Request Participiants im Produkt Jira Service Desk fallen für mich weg, da mit ihnen bzgl. Berechtigungen und Vorgangssicherheit keine Feinkonfiguration möglich ist: https://jira.atlassian.com/browse/JRASERVER-45488

Das geht bei Jira erstaunlicherweise nur mit einem Add-On, welches holprigerweise ein zusätzlich sichtbares Feld im Ticket mit sich bringt – aber diese Kröte muss man an dieser Stelle wohl schlucken …

Wir installieren also das Add-On Jira Watcher Field.

Dann schalten wir beim Add-On Allow users to be added as watchers regardless of Browse Issue permissions ein, denn ohne diesen Trick kann niemand einem Ticket zugeordnet werden, wenn er nicht die grundlegende Berechtigung Projekte durchsuchen hat.

Anschließend machen wir das neue Watcher Field verfügbar:

Und nennen es anschließend Ticket-Beobachter.

Als nächstes wird dieses benutzerdefinierte Feld noch für die entsprechenden Bildschirmmasken freigeschaltet.

Meines Erachtens ist es sinnvoll, die Projekt-Berechtigungen der Autoren auch 1:1 auf die Ticket-Beobachter zu übertragen. Also schalten wir im nächsten Schritt folgende Berechtigungen für die Ticket-Beobachter ebenfalls frei:

  • Projekte durchsuchen (damit das Ticket überhaupt eingesehen werden kann)
  • Vorgänge schließen (damit auch die Ticket-Beobachter ‚tote‘ Tickets wegräumen können)
  • Beobachter verwalten (damit jeder Ticket-Beoachter weitere Ticket-Beobachter hinzufügen kann)
  • Kommentar hinzufügen (jeder, der ein Ticket einsehen kann, sollte auch seinen Senf dazugeben dürfen)
  • Eigene Kommentare löschen
  • Eigene Kommentare bearbeiten
  • Anhänge erstellen
  • Eigene Anhänge löschen

Seltsamerweise reicht es nicht Beobachter verwalten an das Feld Ticket-Beobachter freizugeben, man muss zusätzlich noch für die Gruppe jira-users Beobachter verwalten freischalten

Die Projekt-Benachrichtigungen sind ebenfalls noch um die Ticket-Beobachter zu erweitern, z.B. so:

  • Vorgang erstellt
  • Vorgang geschlossen
  • Vorgang kommentiert
  • Vorgang erneut geöffnet

JIRA: Ticketerstellung per URL

Quelle mit weiteren Hintergründen

Einschrittiger Dialog mit festgelegtem Vorgangstypen

Ohne Fehlermeldung, wenn die Zusammenfassung (= Überschrift) fehlt:

z.B. http://deinserver/secure/CreateIssueDetails!default.jspa?pid=10101&issuetype=10402

Achtung: „To have the reporter field default to the currently logged in user, the user must be logged in and must not have the Modify Reporterpermission.“

Achtung: Es gibt wahrscheinlich keine Möglichkeit, Jira so zu konfigurieren, dass man in diesem Dialog noch zwischen verschiedenen Issue-Types auswählen kann. Das wäre dann nur über den u.g. Vordialog abbildbar.

Mit Fehlermeldung, wenn die Zusammenfassung (= Überschrift) fehlt:

z.B. http://deinserver/secure/CreateIssueDetails!init.jspa?pid=10101&issuetype=10402

Zweischrittiger Dialog mit auswählbarem Vorgangstypen

z.B. http://deinserver/secure/CreateIssue!default.jspa?selectedProjectId=10101&issuetype=10402

Jira konfigurieren

Das abgespeckteste Projekttyp scheint mir Aufgabenverwaltung – daher nutze ich diesen als Ausgangspunkt meines Jira-Proof Of Concepts.

Hipchat-Anzeige nervt, wenn man kein Chat-Tool verwenden möchte. Da dieses Feature ohnehin abgekündigt ist, deaktiviere alle (drei) Plugins mit Hipchat im Namen.

Um Stichworte (engl. Tags) aus allen Anzeigen rauszunehmen, blende es in der entsprechenden Feld-Konfiguration aus.

Sinnvolles Prioritäten-Schema erstellen und Deinem Projekt zuweisen.

CC-Funktionalität abbilden

Abstimmen (engl. Voting) abschalten, weil das den Otto-Normal-Nutzer erstmal verwirren dürfte: System->General Configuration->Allow users to vote on issues (kann man nicht Projekt-fein abschalten, nur Installations-weit)

Für mich ist der Standard-Workflow etwas zu kompliziert. Ich habe also einen einfachen Workflow eingerichtet mit nur drei Status: OPEN, IN ARBEIT und GESCHLOSSEN. Damit beim Übergang in den Status geschlossen eine Benachrichtigung per E-Mail ausgelöst werden kann, muss das explizit konfiguriert werden.

Die linke Projekt-Seitenleiste ausblenden.

Mögliche Painpoints

– Konfiguration ist nicht trivial – 2-3 Mannwochen Einarbeitungszeit erforderlich; danach sollte man (fast) alle Konfigurationswünsche umsetzen können.
– Viele Anpassungswünsche sind nicht out-of-the-box umsetzbar (hier ruht sich Atlassian m.E. etwas zu sehr auf seiner marktbeherrschenden Stellung aus). Die meisten Wünsche davon sind jedoch irgendwie über den Einsatz eines Addons lösbar.
Kann nicht wirklich mehrere Bearbeiter (engl. Assignees) zuordnen. Das gefällt mir aber eigentlich, weil es dem Prinzip Ownership entgegen kommt: es gibt genau einen Mitarbeiter, der für die Lösung eines Auftrags verantwortlich ist.
Mehrere verschiedene Create-Issue-Masken (z.B. für jede Rolle eine eigene) sind schwer implementierbar.
Spaltenbreite der Dashboards nicht anpassbar.
Feld: Prioritäten in Wichtigkeit umbenennen ist etwas umständlich nur über das Languagefile möglich.
– Jira bietet keine Lösung, die Projekt Seitenleiste per default zu verstecken oder einzuklappen.