Alle Vorgänge in Jira werden in Projekten verwaltet. Ein solches Projekt kann z.B. die Vorgänge eines Teams, eines Produktes oder eines „echten“ Projektes beinhalten. Dabei kann jedes Jira-Projekt individuelle Vorgangstypen, Workflows, Berechtigungen, Benachrichtigungen etc. besitzen. Wie man ein neues Projekt anlegt und richtig konfiguriert, erfahren Sie in diesem Artikel.
Projekttyp auswählen
Zunächst gilt es, einen geeigneten Projekttyp auszuwählen. Da diese Entscheidung manchmal nicht einfach ist und sich ggf. nicht rückgängig machen lässt, habe ich der Unterscheidung von Projekttypen einen eigenen Artikel gewidmet. Die nachfolgende Anleitung bezieht sich ausschließlich auf die klassischen, vom Unternehmen verwalteten Jira-Projekte.
Projekt anlegen
Zunächst muss das neue Projekt von einem Administrator angelegt werden. In der zugehörigen Maske muss ein Name und ein Schlüssel eingegeben werden. Der Projektschlüssel wird jedem Vorgangsschlüssel vorangestellt – die Vorgänge im Projekt „MAR“ heißen also „MAR-1“, „MAR-2“ usw.
Best Practice: beim Erstellen eines Projektes kann die Checkbox „Einstellungen mit einem existierenden Projekt teilen“ ausgewählt werden. In diesem Fall werden für das neue Projekt keine zusätzlichen Schemas erstellt, sondern es wird in die bereits vorhandenen Schemas des gewählten Projektes hinzugefügt. Auf diese Weise können beliebig viele Projekte dieselben Schemas verwenden. Legt man sich auf einige Standardschemas fest (z.B. jeweils ein Set an Schemas für Software-Projekte, Aufgabenprojekte, Teamprojekte), bleibt die Administration übersichtlich. Nachteil: erstellt man auf diese Weise ein Kanban-Projekt, wird nicht automatisch ein Board erzeugt, sondern muss manuell angelegt werden.
Vorgangstypen auswählen
Jedem Projekt kann ein individuelles Vorgangstypschema zugewiesen werden. Ein solches Schema legt fest, welche Vorgangstypen in einem Projekt zur Verfügung stehen. Prinzipiell rate ich meinen Kunden, in einem Projekt nur diejenigen Vorgangstypen zuzulassen, die auch wirklich benötigt werden. Werden z.B. in einem Marketing-Projekt keine Bugs eingestellt, sollte dieser Vorgangstyp den Benutzern auch nicht zur Verfügung stehen. Zusätzlich kann sowohl die Reihenfolge als auch der standardmäßig vorausgewählte Vorgangstyp eingestellt werden.
Achtung: die projektbezogene Berechtigung „Vorgänge erstellen“ bezieht sich auf alle in einem Projekt verfügbaren Vorgangstypen. Eine Einschränkung bestimmter Vorgangstypen auf einzelne Gruppen oder Projektrollen ist nicht möglich (siehe https://jira.atlassian.com/browse/JRA-5865).
Benutzerdefinierte Felder anlegen
Jeder Vorgang in Jira besitzt verschiedene Attribute, z.B. Name, Typ, Status, Priorität. Diese standardmäßigen Attribute können durch benutzerdefinierte Felder projekt- und vorgangstypabhängig erweitert werden. Bsp.: möchte man den Vorgangstyp „Support-Ticket“ im Projekt „Support“ um ein zusätzliches Feld „Name des Kunden“ erweitern, legt man ein gleichnamiges benutzerdefiniertes Feld an und weist diesem im „Kontext“ das entsprechende Projekt und den gewünschten Vorgangstyp zu. Im nächsten Schritt wählt man nur noch aus, in welchen Bildschirmmasken das neue Feld bearbeitet werden kann, und hat damit erfolgreich ein neues benutzerdefiniertes Feld angelegt.
Auch bei benutzerdefinierten Feldern rate ich meinen Kunden zu Sparsamkeit. Ein neues Feld kann zwar prinzipiell für alle Projekte, Vorgangstypen und Bildschirmmasken gleichzeitig freigegeben werden – ratsam ist aber, nur diejenigen Kontexte auszuwählen, in denen das Feld tatsächlich benötigt wird. Andernfalls überfüllt man die vorhandenen Bildschirmmasken mit unnützen und damit irreführenden Feldern.
Weitere Informationen zu benutzerdefinierten Felder unter Jira: Benutzerdefinierte Felder.
Workflows einrichten
Nachdem die Vorgangstypen für das neue Projekt ausgewählt wurden, muss nun entschieden werden, welche Arbeitsabläufe diese Vorgangstypen in diesem Projekt verwenden sollen. Dabei muss fachlich geprüft werden, ob die bereits vorhandenen Arbeitsabläufe für das neue Projekt verwendet werden können:
- Verwenden alle Projekte für diesen Vorgangstyp die gleichen Schritte und Übergänge?
- Werden unterschiedliche Workflowberechtigungen benötigt?
- Ist absehbar, dass sich die Anforderungen eines der Projekte bald ändern werden?
Abhängig von diesen Kriterien können nun entweder bestehende Arbeitsabläufe zu einem neuen Arbeitsablaufschema zusammengefasst und dem neuen Projekt zugewiesen werden, oder neue Arbeitsabläufe angelegt werden.
Näheres zum Anlegen von Arbeitsabläufen unter Jira FAQ: Workflows sowie Jira Workflows: Best Practices und typische Fehler.
Projektrollen einrichten
In jedem Projekt sollten fachliche Projektrollen definiert und die Nutzer in Jira entsprechend zugeordnet werden. Die Arbeit mit Projektrollen (statt mit konkreten Nutzern) erleichtert u.a. die Zuordnung von Berechtigungen und Benachrichtigungen. Achtung: Projektrollen werden global angelegt – das bedeutet, dass in allen Projekten alle Projektrollen zur Verfügung stehen.
Näheres zur Arbeit mit Projektrollen unter Jira FAQ: Projekte und Projektrollen und Jira: Plädoyer für Projektrollen.
Berechtigungsschema anlegen
Beinahe jedes Projekt im produktiven Einsatz benötigt ein individuelles Berechtigungsschema. Das Berechtigungsschema legt fest, welche Projektrollen über welche Berechtigungen in diesem Projekt verfügen. Hier wird z.B. gesteuert, wer das Projekt und die darin enthaltenen Vorgänge sehen darf , wer neue Vorgänge erstellen oder bestehende Vorgänge in diesem Projekt löschen darf. Bei der Arbeit mit Berechtigungen in Jira gibt es 2 mögliche Ansätze:
- Autonom: einer Berechtigung werden alle Projektrollen zugeteilt, die diese Berechtigung besitzen sollen. Bsp.: Administratoren, Entwickler und Nutzer sollen Vorgänge löschen dürfen. Demzufolge erhalten die Projektrollen „Administrator“, „Developer“ und „User“ die Berechtigung „Vorgang löschen“.
- Vorteil: jedem Nutzer muss nur eine Rolle zugewiesen werden und er erhält damit automatisch alle ihm zustehenden Berechtigungen.
- Nachteil: das Berechtigungsschema kann unübersichtlich werden.
- Hierarchisch: die Projektrollen werden als Hierarchie aufgefasst und einer Berechtigung wird nur die „niedrigste“ Projektrolle zugewiesen. Bsp.: die Berechtigung „Vorgang löschen“ erhält nur die Projektrolle „User“.
- Vorteil: kleinere und übersichtliche Berechtigungsschemas.
- Nachteil: ein Nutzer muss seine „höchste“ Projektrolle und auch alle niedrigeren Rollen erhalten. Bsp: ein Nutzer der Projektrolle „Administrator“ muss gleichzeitig die Rollen „Developer“ und „User“ erhalten, damit er alle notwendigen Berechtigungen erhält.
Ich rate meinen Kunden stets, die Projektrollen autonom zu behandeln und sich damit für Variante 1 zu entscheiden. Der ausschlaggebende Vorteil dieser Variante ist die niedrigere Fehleranfälligkeit. Die Komplexität liegt hier bei den Administratoren, nicht bei den Projektleitern. Ein Projektleiter muss damit jedem Teammitglied nur eine einzige Rolle zuweisen, statt z.B. zu überlegen, welche Rollen einem neuen „Developer“ nun zugewiesen werden müssen, damit er in Jira arbeiten kann. Leider verwendet das Standardberechtigungsschema in Jira Variante 2 – hier sollte man als Admin also Vorarbeit leisten und seine Berechtigunggschemas entsprechend anpassen.
Weitere Informationen zu Berechtigungen unter Jira: Berechtigungen, Berechtigungsschemas und Sicherheitslevels.
Bildschirmmasken anlegen
In Jira ist jedem Projekt ein „Bildschirmmaskenschema für Vorgangstypen“ zugeordnet. Darin wird festgelegt, welcher Vorgangstyp welches Bildschirmmaskenschema verwenden soll. So kann z.B. für den Vorgangstyp „Aufgabe“ ein anderes Bildschirmmaskenschema verwendet werden als für den Vorgangstyp „Softwarefehler“. Werden für ein Projekt individuelle Bildschirmmasken benötigt (z.B. weil neue benutzerdefinierte Felder angelegt wurden, die nur in diesem Projekt angezeigt werden sollen), müssen entsprechende Bildschirmmasken und Bildschirmmaskenschemas angelegt und einem Bildschirmmaskenschema für Vorgangstypen zugeordnet werden.
Näheres zu Bildschirmmasken unter Jira: Bildschirmmasken und Bildschirmmaskenschemata.
Benachrichtigungen definieren
Für jedes Projekt in Jira kann ein Benachrichtigungsschema definiert werden. Ein solches Schema legt fest, bei welchen Ereignissen an welche Benutzer eine Benachrichtigung per E-Mail versendet werden soll. Bsp.: in einem Projekt „Support“ erhält der Projektleiter eine Benachrichtigung per E-Mail, wenn ein Vorgang erstellt wird oder in den Status „eskaliert“ übergeht. Als Empfänger einer Benachrichtigung können u.a. einzelne Nutzer, Gruppen, Rollen, Mailadressen, der Autor, der aktuelle Bearbeiter, der Projektleiter sowie Benutzer in benutzerdefinierten Feldern angegeben werden.
Achtung: Benachrichtigungen sind unabhängig vom Vorgangstyp – in einem Projekt werden für alle Vorgangstypen die gleichen Benachrichtigungen versendet.
Sicherheitsschema einrichten
Innerhalb eines Projektes kann es notwendig sein, die Sichtbarkeit einzelner Vorgänge auf bestimmte Nutzerkreise zu beschränken. Jira setzt diese Anforderung durch Sicherheitsschemata um. Innerhalb eines Sicherheitsschemas werden Sicherheitsstufen definiert und mit einzelnen Benutzern, 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 z.B. eine Sicherheitsstufe „Administratoren“ angelegt und der Benutzergruppe „jira-administrators“ zugeordnet werden. Alle Vorgänge, für die diese Sicherheitsstufe ausgewählt wird, sind dann ausschließlich für Mitglieder der Gruppe „jira-administrators“ sichtbar.
Achtung: beim Erstellen eines Sicherheitsschemas sollte eine Standardstufe festgelegt werden, die alle neu erstellte Vorgänge automatisch erhalten. 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. Andernfalls kann es schnell passieren, dass unbewusst Vorgänge ohne Sicherheitsstufe erstellt werden.
Komponenten und Versionen anlegen
Falls notwendig, können für ein Projekt Komponenten und Versionen angelegt werden. Komponenten stellen eine zusätzliche Gliederungsmöglichkeit für Vorgänge dar: in einem Softwareentwicklungsprojekt können z.B. Komponenten für GUI, Datenbank und Anwendungslogik angelegt werden. Vorgänge können dann einer oder mehreren Komponenten zugeordnet werden. Zusätzlich kann für jede Komponente ein Komponentenleiter bestimmt und als standardmäßiger Bearbeiter für neue Vorgänge ausgewählt werden.
Versionen können für verschiedene Lebenszyklen von Projekten verwendet werden. Im Beispiel des Softwareentwicklungsprojektes können verschiedene Versionen für Alpha-, Beta- und Releaseversionen angelegt werden. Sowohl die standardmäßigen Übersichten als auch die Dashboard-Widgets beziehen Versionen in ihre Übersichten mit ein (z.B. Anzeige der noch offenen Vorgänge für eine Version, Anzeige alle gelösten Vorgänge einer Version inkl. automatischer Releasenotes etc.).
Fazit
Beim Einrichten eines neuen Projektes in Jira sollte einige Zeit in die Planung und Konzeption der notwendigen Vorgangstypen, Arbeitsabläufe, Schemas und Einstellungen gesteckt werden. Erstellt man ein Projekt „quick and dirty“, wird es später um so aufwendiger, die durch unsaubere Konfiguration aufgetretenen Probleme zu beheben.
Ein weiterer Punkt, den ich meinen Kunden nur ans Herz legen kann: Dokumentation. Nur wenn den Nutzern einfache Übersichten zur Verfügung stehen, z.B. über die mit einer Projektrolle verbundenen Berechtigungen, kann das System langfristig gut benutzt und akzeptiert werden. Für die Dokumentation solcher Projekte empfehle ich natürlich Atlassian Confluence.
Hallo Herr Höhne,
lt. Atlassian-Dokumentation kann ein Jira-Projektleiter Komponenten und Versionen anlegen. Obwohl wir das Jira-Standardberechtigungsschema verwenden, hat der Jira-Projektleiter nicht das Recht, Komponenten und Versionen anzulegen.
Wo kann ich noch suchen? Woran kann das liegen?
Vielen Dank,
mit freundlichen Grüssen
Ulla Schneider
Hallo Frau Schneider,
der Projektleiter hat standardmäßig keine besonderen Rechte, er wird nur bei neu erstellten Tickets automatisch als Bearbeiter ausgewählt. Das Recht, die Komponenten und Versionen eines Projektes zu verwalten, wird im Berechtigungsschema über die Berechtigung „Projekte verwalten“ erteilt (siehe „Managing Project Permissions„). Wenn bei Ihnen der Projektleiter die Versionen und Komponeten des Projektes verwalten soll, müssen Sie also noch in das Berechtigungsschema des entsprechenden Projektes gehen und dort bei der Berechtigung „Projekte verwalten“ die Einstellung „Projektleitung“ hinzufügen. Damit hat dann immer automatisch der Projektleiter das Recht, das Projekt zu verwalten.
Beste Grüße,
Sebastian Höhne
Hat geklappt! Vielen Dank für die schnelle Antwort.
Beste Grüsse,
Ulla Schneider
Hallo Herr Höhne,
ich habe ein Problem beim Anlegen von neuen Projekten:
nachdem ich alle Angaben für das Projekt eingegeben habe und mit dem senden/submit button abschicke rödelt die sanduhr dauerhaft und es passiert nichts mehr. Wenn ich den Vorgang abbreche und die seite aktualisiere ist das Projekt angelegt.
Haben sie einen Hinweis, wo der Fehler liegen könnte ?
Herzlichen Dank
Holger Faulhaber
Hallo Herr Faulhaber,
tritt der Fehler bei allen Projekttypen auf, oder nur wenn Sie Scrum/Kanban als Projekttyp auswählen? Wenn zweiteres der Fall ist: beim Erstellen eines agilen Projektes wird gleichzeitig ein Agile-Board angelegt, und dafür benötigt man die globale Berechtigung „Freigegebene Objekte erstellen“. Diese Berechtigung ist standardmäßig nur an die Gruppe jira-users vergeben. Sofern Sie als Admin kein Mitglied dieser Gruppe sind, können Sie entweder auch der Gruppe jira-administrators diese Berechtigung erteilen (Globale Administration – System – Globale Berechtigungen – Freigegebene Objekte Erstellen), oder anders herum sich selbst mit in die Gruppe jira-users packen.
Falls man als Admin kein Mitglied von jira-users ist, muss man auch darauf achten, im Standardberechtigungsschema auch der Rolle „Administrators“ das Recht „Projekte durchsuchen“ zu erteilen, sonst hat man zunächst keine Leseberechtigung für das neu erstellte Projekt (bzw. Agile erkennt das und lässt einen gar kein Projekt erstellen, wenn man diese Berechtigung nicht besitzt).
Falls das nicht hilft: der Create-Project Dialog ist bei Fehlern leider nicht besonders mitteilsam und bleibt dann wie bei Ihnen einfach hängen. Sie können dann aber zumindest im Log (Home-Verzeichnis/log/atlassian-jira.txt) oder mit einer Javascript Netzwerkkonsole schauen, wegen welcher Fehlermeldung sich der Dialog aufgehangen hat.
Beste Grüße,
Sebastian Höhne
Hallo Herr Höhne,
erst einmal super Arbeit Sie hier leisten!
Nun zu meiner Frage, gibt es eine Möglichkeit bei den Benachrichtigungsschemata ein eigenes Ereignis hinzuzufügen?
z .B. Ereignis „Externer Review“ > und das ich dort wie bei z. B. „Vorgang erstellen“ einstellen kann wer benachrichtigt wird?!
Vielen Dank im Voraus
Michael Kernchen
Hallo Herr Kernchen,
vielen Dank! 🙂 Ja das geht, Sie können in der globalen Administration unter System – Erweitert – Ereignisse ein eigenes Ereignis hinzufügen. Dieses Ereignis können Sie dann bei einem beliebigen Statusübergang eines Arbeitsablaufes als Folgefunktion auslösen (ganz unten in der Liste der Folgefunktionen). In den Benachrichtigungsschemas taucht das neue Ereignis ebenfalls mit auf und Sie können dort die Benachrichtigungen festlegen.
Beste Grüße aus Dresden,
Sebastian Höhne
P.S. In der Doku von Atlassian ist das auch nochmal genauer ausgeführt: https://confluence.atlassian.com/display/JIRA/Adding+a+custom+event
Sehr geehrte Herr Höhne,
vielen Dank für die schnelle Antwort. Nun habe ich ein Problem, wo ich hoffe, dass Sie mir vielleicht helfen können. Ich konnte eine ganze Weile unter Vorgänge > Status hinzufügen , einen neuen Status hinzufügen und diesen dann bei Benachrichtigungsschemata auch hinzufügen…z.B. das ich dann benachrichtigt werde. Nun zum Problem, wenn ich nun einen Status hinzufüge (über System) und diesen dann in ein Benachrichtigungsschemata hinzufügen will, dann wird mir der neu angelegte Status aber nicht angezeigt. Was kann das sein? Vielen vielen Dank im Voraus.
Hallo Herr Kernchen,
kam die Funktion ggf. über ein Plugin? Im Standard verhät es sich so: Sie legen einen neuen Status an und bauen diesen Status in einen Arbeitsablauf ein. Wenn Sie benachrichtigt werden möchten, sobald ein Vorgang in diesen Status übergeht, müssen Sie zusätzlich ein neues Ereignis („System“ – „Ereignisse“) hinzufügen. Dieses Ereignis können Sie im Arbeitsablauf bei jedem beliebigen Statusübergang auslösen, indem Sie den Statusübergang anklicken und dann rechts bei „Folgefunktionen“ in der Liste ganz unten das neu erstellte Ereignis auswählen. Immer wenn ein Nutzer diesen Statusübergang durchführt, wird das zugeordnete Ereignis ausgelöst. Als letzen Schritt müssen Sie dann nur noch ins Benachrichtigungsschema gehen, sehen dort das neu erstellte Ereignis und können diesem Ereignis Benachrichtigungen zuweisen.
Also wie eingangs gesagt: dass beim Anlegen eines neuen Status automatisch ein Ereignis erstellt wird, welches man dann im Benachrichtigungsschema auswählen kann, ist mir nicht bekannt, könnte ggf. aus einem Plugin gekommen sein.
Grüße aus Dresden,
Sebastian Höhne
Sehr geehrte Herr Höhne,
ich würde gerne ein Benutzerdefiniertes Feld nur für bestimmte Benutzergruppen (Administratoren) sichtbar oder editierbar machen.
Ich habe sämtliche Einstellungen kontrolliert aber leider keine Weg gefunden es so einzustellen.
Ich bin mir sicher es gibt eine Möglichkeit allerdings finde ich diese nicht.
Über Ihre Antwort würde ich mich sehr freuen.
Beste Grüße aus Südtirol
Thomas Alber
Hallo Herr Alber,
das geht mit Bordmitteln leider nicht – allerdings können Sie diese Funktion mit dem kostenlosen Script Runner Plugin (https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner) umsetzen. Wenn Sie das Plugin installieren, finden Sie danach einen neuen Punkt „Behaviours“ in den Plugin-Funktionen. Dort können Sie das Verhalten einzelner Felder steuern, z.B. ein Feld nur für eine bestimmte Rolle sichtbar/editierbar machen oder nur in einem bestimmten Status editierbar machen etc.
Ein Beispiel, das genau Ihre Anforderung abdecken sollte, finden Sie in der Doku: https://jamieechlin.atlassian.net/wiki/display/JBHV/JIRA+Behaviours+Plugin#JIRABehavioursPlugin-Makeafieldread-onlyexceptforacertainrole
Beste Grüße,
Sebastian Höhne
Hallo Sebastian,
eine Frage zu den Versionen: wie schaffe ich es, ein Ticket einer Version zuzuordnen?
LG Ulli
Hallo Ulli,
eigentlich müsste in den Vorgangsdetails oder im Bearbeiten-Dialog ein Feld „Lösungsversion“ zu sehen sein. Falls das nicht der Fall ist, kann das verschiedene Gründe haben, am wahrscheinlichsten ist aber, dass für dieses Projekt noch keine Versionen erstellt wurden. D.h. du (oder jemand mit der Berechtigung, das Projekt zu administrieren) musst dafür in die Projektadministration gehen und dort unter dem Punkt „Versionen“ mindestens eine Version hinzufügen. Danach sollte das Feld dann auch in den Vorgängen zu sehen sein. Falls nicht: wenn du den Bearbeiten-Dialog des Vorgangs öffnest, siehst du rechts oben einen Button „Felder konfigurieren“. Wenn du da draufgehst, erscheint eine Option „Wo ist mein Feld?“. Wenn du dort „Lösungsversion“ eingibst, wird dir angezeigt, aus welchem Grund das Feld nicht zu sehen ist.
Beste Grüße,
Sebastian
Sehr geehrter Herr Höhne,
wir haben bei uns ein JIRA (6.4) mit Agile Addon eingerichtet. Wir verwenden nun Sprints und BacklogItems – soweit ist alles fein.
Wenn wir zu Vorgängen vom Typ Aufgaben nun Unteraufgaben anlegen, sehen wir in der Vater-Aufgabe zwar alle zugeordneten Unteraufgaben, aber in den Unteraufgaben nicht den Link zur Vateraufgabe. Gibt es die Möglichkeit, dies in der Aufgaben-Einzelansicht anzuzeigen?
Viele Grüße,
Christoph Pertzsch
Hallo Herr Pertzsch,
in den Untervorgängen wird diese Beziehung leider nicht so schön dargestellt, wie im jeweiligen Hauptvorgang. Einen Link zum Hauptvorgang gibt es aber auch in der Einzelansicht des Untervorgangs: direkt über der Zusammenfassung des Vorgangs befindet sich die Breadcrumb-Navigation, dort befindet sich der Link zum jeweiligen Hauptvorgang.
Es gibt anscheinend auch ein (kostenfreies) Plugin, mit dem man die Zusammenfassung und Beschreibung des Hauptvorgangs als benutzerdefiniertes Feld in die Untervorgänge einbauen kann: https://docs.servicerocket.com/display/PIS/Parent+Issue+Summary . Das habe ich aber noch nicht getestet, kann also erstmal nichts Genaueres dazu sagen.
Beste Grüße,
Sebastian Höhne
Hallo,
ich möchte das Service Desk gern los werden und meinen Kunden direkt ins Jira lassen, die Einstellungen das er nur sein Projekt sehen darf sind getroffen. Auch die Sicherheitseinstellungen funktionieren tadellos, das was mich jetzt aber noch stört ist die Tatsache das der Kunde alle Projekte sehen kann wenn er ein Ticket erstellt bei der Auswahl des Projektes. Kann man das noch auf die ihm zugewiesenen reduzieren?
Hallo,
für das „Kundenprojekt“ muss man ein eigenes Berechtigungsschema verwenden. Wenn man in einem Berechtigungsschema in die Berechtigung „Projekte durchsuchen“ die Rolle „Autor“ hinzufügt, wird das Projekt automatisch für alle Jira-Nutzer beim Erstellen von Vorgängen auswählbar (muss auch so sein, denn jeder Jira-Nutzer könnte ein potentieller „Autor“ sein). Wenn für alle Projekte das selbe Berechtigungsschema verwendet wird und dort überall der Autor bei „Projekte durchsuchen“ drin ist, sind in Konsequenz alle Projekte für alle Nutzer beim Vorgang erstellen auswählbar.
Also: für das Kundenprojekt ein eigenes Berechtigungsschema verwenden und nur in diesem Schema die Einstellung mit dem Autor vornehmen. Alternativ gibt es auch noch eine „versteckte“ Funktion von Jira: https://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission. Wenn man besagte Zeile aktiviert, gibt es eine neue Berechtigungsoption „Reporter (show only projects with create permission)“. Wenn man diese statt nur „Autor“ verwendet, sehen nicht mehr alle Nutzer das Projekt, sondern nur noch die, die zusätzlich die Berechtigung zum Erstellen von Vorgängen in diesem Projekt haben. Wäre also ebenfalls eine Möglichkeit – ich würde es aber zunächst einfach mit einem separaten Berechtigungsschema versuchen.
Grüße,
Sebastian
P.S. Zweiteren Lösungsvorschlag habe ich persönlich noch nicht getestet.
Hallo,
wie kann man einer Komponente einen Vorgang zuweisen. Wenn ich über die Buttons in jira gehe, landen alle meine Vorgänge im Standardordner des Projektes und bei den Komponenten wird kein Vorgang angezeigt.
Grüße
Eric
Hallo Herr Jourdan,
zunächst müssen Sie für ein Projekt angeben, welche Komponenten es in diesem Projekt geben soll (in der Projektverwaltung im Punkt „Komponenten“, dafür braucht man die Berechtigung „Projekt verwalten“). Wenn Sie in einem Projekt Komponenten angelegt haben und danach einen Vorgang aus diesem Projekt bearbeiten, sehen Sie, dass Sie jetzt das Feld „Komponente“ ausfüllen können. Damit können Sie den Vorgang einer (oder mehreren) Komponenten dieses Projektes zuweisen. Wenn Sie danach nach Vorgängen suchen, können Sie z.B. alle Vorgänge anzeigen lassen, die zu einer bestimmten Komponente gehören.
Sollte das Feld „Komponente“ in der Bearbeiten-Maske Ihres Vorgangs nicht zu sehen sein, können Sie in dieser Maske rechts oben die Funktion „Felder konfigurieren“ – „Wo ist mein Feld?“ aufrufen. Darin wird Ihnen angezeigt, warum das Feld nicht in der Maske enthalten ist und wie Sie es hinzufügen können.
Beste Grüße,
Sebastian Höhne
Hallo Herr Höhne,
ich bin gerade auf eine interessante Fragestellung gestoßen und zwar gibt es die Möglichkeit für einen Vorgangstyp einen bestimmten (Standard)- Bearbeiter zu definieren?
VG
F.Lohmeier
Hallo Herr Lohmeier,
nicht direkt – das funktioniert entweder über den Umweg einer Komponente oder über die Arbeitsabläufe. Zur Komponente: Sie können in einem Projekt Komponenten definieren und für jede Komponente einen „Komponentenleiter“ festlegen. Wird ein Vorgang erstellt und eine Komponente ausgewählt, wird der Vorgang dem Komponentenleiter zugewiesen (siehe hier). Zusätzlich können Sie bei dieser Variante auch bei jedem Statusübergang im Arbeitsablauf festlegen, dass der Vorgang dem Komponentenleiter zugewiesen werden soll.
Die Alternative zur Komponente: Sie können in den Arbeitsabläufen der betreffenden Vorgangstypen im „Create“-Statusübergang eine Folgefunktion hinzufügen, die den Vorgang einem bestimmten Bearbeiter zuweist. Standardmäßig kann man einen festen Nutzer hinterlegen; mit einem Plugin wie den „Misc Workflow Extensions“ oder der „Workflow Toolbox“ hat man aber noch mehr Möglichkeiten, z.B. den Vorgang demjenigen Mitglied einer bestimmten Rolle zuweisen, dem der Vorgang zuletzt zugewiesen war.
Beste Grüße,
Sebastian Höhne
Sehr geehrter Herr Höhne,
ich habe eine kleine Frage zur Projekt-Ansicht in JIRA. Wenn ich ein Projekt auswähle bekomme ich anschließend eine Liste aller Vorgänge dieses Projekts angezeigt. Ich kann diese nun auch beliebig sortieren und filtern. Allerdings werden mir an dieser Stelle nur der Vorgangsschlüssel und der Name des Vorgangs angezeigt. Gibt es eine Möglichkeit an dieser Stelle auch den Bearbeiter sowie Status und z.B. die Priorität anzeigen zu lassen?
Viele Grüße
Antonia Groß
Hallo Frau Groß,
diese Ansicht kann man leider nicht konfigurieren, da muss man sich also leider „durchklicken“. Evtl. hilft Ihnen aber die Tabellenansicht im Vorgangsnavigator weiter: wenn Sie sich in der erwähnten Vorgangsliste befinden, können Sie rechts oben auf den Link „Alle Vorgänge und Filter anzeigen“ klicken, dann öffnet sich der Vorgangsnavigator. (alternativ auch über „Vorgänge“ – „Nach Vorgängen suchen“ erreichbar)
Darin können Sie rechts per Button zwischen Listen- und Detailansicht umschalten. Wenn Sie hier die Listenansicht wählen, werden Ihnen als Spalten auch der aktuelle Bearbeiter, Status und Priorität angezeigt. Die Spalten können Sie dann auch selber frei sortieren / auswählen.
Beste Grüße,
Sebastian Höhne
Sehr geehrter Herr Höhne,
meistens werde ich ja auf ihrer Seite direkt fündig, aber dieses Mal muss ich fragen…
1. In unserem Projekt arbeiten wir mit diversen Vorgängen die wir einer oder mehreren Komponenten zuordnen. Ein erstellter (projektweiten) Filter zeigt alle Vorgänge die eine „genaue“ Komponente enthalten (vollständig an).
2. In Confluence haben wir Seite gebaut, die das Ergebnis des Filters (über Einfügen\„Jira-Vorgang/-Filter“) anzeigt. In der Anzeige wird auch das Feld „Komponente(n)“ angezeigt.
Das Problem das jetzt besteht ist, dass das Feld „Komponente(n)“ in Confluence leer angezeigt wird, wenn dem Vorgang mehr als eine Komponente zugeordnet ist (bei der Anzeige des gleichen Filters in Jira mit der Spalte Komponente(n) sind in dieser alle Einträge dargestellt (egal ob der Vorgang einer oder mehreren Vorgängen zugeordnet ist).
Können Sie uns hier eventuell mit einer Lösung behilflich sein?
Vielen Dank im Voraus und freundliche Grüße,
Marco Wagner
Hallo Herr Wagner,
das klingt nach https://jira.atlassian.com/browse/CONFSERVER-38779
– passt der Bug zu Ihrer Confluence-Version? Dann sollte das Problem nach einem entsprechenden Update behoben sein.
Beste Grüße,
Sebastian Höhne
Hallo Herr Höhne,
vielen Dank! Passt genau! Jetzt gilt es nur noch darauf zu warten, wann wir von der Version 5.8.18 zur aktuellen aufschließen…oder doch zumindest etwas aktuelleren:-)
Gruss,
Marco Wagner
Moin Herr Höhne,
ich finde einfach nirgends die Antwort auf meine Frage. Vielleicht kennen Sie sie ja 🙂
Ist es in Jira irgendwie möglich, ein Projekt anzulegen, aber nur einer bestimmten, eigens dafür angelegten Gruppe von Nutzern zu gestatten, das auch zu sehen? Vielen Dank schonmal.
Hallo Herr Schade,
das ist kein Problem: das neu angelegte Projekt wird automatisch einem Berechtigungsschema (Globale Administration – Vorgänge – Berechtigungsschemata) zugeordnet. In diesem Schema können Sie in der Berechtigung „Projekt durchsuchen“ festlegen, wer dieses Projekt sehen darf. Das können typischerweise Nutzergruppen oder Projektrollen sein. Wenn Sie Nutzergruppen verwenden, können Sie als Admin „statisch“ festlegen, welche Nutzergruppen Zugriff auf dieses Projekt haben. Wenn Sie Projektrollen verwenden, kann der Projektadmin innerhalb des Projektes flexibel entscheiden, welche Nutzer in diesem Projekt in welcher Rolle sein sollen.
Egal welche Variante Sie verwenden: nur die Nutzer, die in dieser Berechtigung eingetragen sind, können das Projekt sehen, die Vorgänge dieses Projektes über die Suche finden etc. (Siehe auch hier)
Beste Grüße,
Sebastian Höhne
P.S. Wenn Sie das Berechtigungsschema bearbeiten, müssen Sie vorher schauen, ob dieses Schema gleichzeitig auch anderen Projekten zugewiesen ist – dann wirken sich die Änderungen gleichermaßen auf diese anderen Projekte aus.
Hallo Herr Höhne,
wir würden gerne die Benachrichtigungen in JRIA so einstellen, dass der Kollege, dem ein Vorgang als Bearbeiter zugewiesen wird, in dem Moment eine Benachrichtigung bekommt.
Wir haben dazu in unserem Benachrichtigungsschema bei „Vorgang zugewiesen“ unter anderem „Aktueller Bearbeiter“ eingestellt.
Ich hatte erwartet, dass dann der betroffene Kollege jeweils eine Mail bekommt. Das passiert aber leider nicht.
Haben wir da was falsch verstanden?
Freundliche Grüße
Gisela Lassahn
Hallo Frau Lassahn,
Sie haben alles richtig gemacht – bei „Vorgang zugewiesen“ und „Aktueller Bearbeiter“ sollte der Nutzer, dem ein Vorgang zugewiesen wird, darüber eine Benachrichtigung erhalten. Versendet Ihr Jira denn andere Benachrichtigungen, oder gar keine? Zu beachten ist auch: standardmäßig wird man über die von einem selbst ausgelösten Aktionen nicht benachrichtigt, d.h. wenn Sie sich selbst einen Vorgang zuweisen, dann wird keine Mail versendet. Das führt beim Testen der Einstellungen gerne mal zu Verwirrung.
Beste Grüße,
Sebastian Höhne
Hallo Herr Höhne,
wo kann man eigentlich einstellen, welches Berechtigungsschema als Default genommen werden soll, wenn jemand ein Projekt neu anlegt?
Vielen Dank und freundliche Grüße
Gisela Lassahn
Hallo Herr Höhne,
ich habe folgende Challenge und hoffe, dass Sie die Lösung hierfür parat haben.
Es gibt ein Projekt „a“. Den Inhalt von Projekt „a“ möchte ich kopieren und in Projekt „b“ einfügen. Die „move-to“ Funktion kenne ich – dauert mir aber zu lange für alle Features…
Ich bin auf der Suche nach einer einfachen und effizienten Lösung mit der ich das (am besten gesamte) Projekt „a“ duplizieren kann, ohne jedes einzelne Feature anfassen zu müssen.
Ich freue mich sehr über Ihre Antworten.
Vielen Dank vorab!
Annika Rumpf
Hallo Frau Rumpf,
das sollte leicht möglich sein: über die Suchfunktion können Sie nach allen Vorgängen aus Projekt a suchen (oder einer Teilmenge, wie den offenen Vorgängen) und diese dann per Mehrfachänderung (in der Suchmaske rechts oben, Menüpunkt „Tools“) alle gleichzeitig in Projekt b verschieben. Falls dabei Vorgangstypen, Workflows o.ä. geändert werden müssen, leitet Sie ein Dialog durch die nächsten Schritte.
Die Doku dazu finden Sie unter https://confluence.atlassian.com/jirasoftwareserver/editing-multiple-issues-at-the-same-time-939938937.html
Beste Grüße,
Sebastian Höhne
Vielen Dank Herr Höhne.
Ich freue mich sehr über Ihre Antwort!!
Es kam noch eine Idee im Gespräch mit Kollegen auf:
Ein Gesamt-Projekt zu haben und aus ihm mehrere Varianten (Unterhierarchen) zu erstellen. Diese ergeben somit die „Subprojekte“. Das Ziel ist hierbei die Fehlervermeidung da dann die Änderungen in der obere Hierarchie direkt in den unteren Hierarchien per Algorithmus von Jira nachgezogen werden. Geht das auch?
Sie sind derzeit meine Hoffnung.
Beste Grüße und vorab nochmal Danke
Annika Rumpf