Jira FAQ: Benutzerdefinierte Felder

Eine der Stärken von Jira liegt in seiner umfangreichen Anpassbarkeit. In diesem Sinne ist es Administratoren möglich, die in Jira verwalteten Vorgänge um benutzerdefinierte Felder zu erweitern. Das ist in zahlreichen Fällen auch notwendig, da die standardmäßigen Vorgangseigenschaften bzw. -felder auf die Gebiete Softwareentwicklung und Bugtracking ausgerichtet sind. Wer Jira in anderen Szenarien einsetzen möchte, kann die dafür benötigten Vorgangstypen und deren Attribute administrativ festlegen.

Globale und kontextbezogene Felder

Benutzerdefinierte Felder können sowohl global aktiviert, als auch auf konkrete Vorgangstypen und Projekte (den sog. „Kontext“ des Feldes) eingeschränkt werden. Erstellt man z.B. ein benutzerdefiniertes Feld „Kundennummer“, kann man dieses entweder für alle Projekte und Vorgangstypen freigeben, oder es auf bestimmte Projekte und Vorgangstypen beschränken. Durch eine solche Beschränkung steht das benutzerdefinierte Feld nur in den Bildschirmmasken des ausgewählten Kontextes zur Verfügung. Meiner Meinung nach eine sehr nützliche Option, die Jira leider an anderer Stelle – u.a. bei Status, Lösungen und Prioritäten – vermissen lässt.

Benutzerdefinierte Felder

Das Menü für das Anlegen benutzerdefinierter Felder steht Administratoren unter VorgängeFelder zur Verfügung. Nach einem Klick auf „Benutzerdefiniertes Feld hinzufügen“ sucht man zunächst einen Feldtyp aus. Zur Auswahl stehen unter anderem:

  • Benutzerauswahl (Einzeln oder Mehrfach),
  • Gruppenauswahl,
  • Freitext,
  • Listen (Einfachauswahl, Mehrfachauswahl, Kaskadierende Auswahl [2 Ebenen]),
  • Checkboxes und Radiobuttons,
  • uvm.

Anmerkung: insbesondere die Feldtypen „Benutzerauswahl“ und „Gruppenauswahl“ sind sehr mächtig, da man diese über die Option „Wert des benutzerdefinierten Benutzerfelds“ sowohl in Berechtigungs- als auch im Benachrichtungsschemata auslesen kann. Dadurch kann man z.B. weiteren Benutzern Berechtigungen für einen konkreten Vorgang erteilen oder zusätzliche Benachrichtigungen versenden.

Im nächsten Schritt vergibt man einen Feldnamen sowie eine Feldbeschreibung (diese wird dann in der späteren Bildschirmmaske als Beschreibung angezeigt) und wählt den Kontext (also die Vorgangstypen und Projekte) aus, in denen das neue Feld zur Verfügung stehen soll. Je nach ausgewähltem Kontext werden nun die verfügbaren Bildschirmmasken angezeigt, in denen man sein neues Feld anzeigen lassen kann. Diesen Schritt kann man getrost auch überspringen, da man die Bildschirmmasken jederzeit anpassen und das benutzerdefinierte Feld auf diese Weise nachträglich an gewünschter Position einbauen kann.

Damit ist das neue benutzerdefinierte Feld angelegt. Je nach gewählten Feldtyp muss man nun die verfügbaren Optionen konfigurieren. In der Übersicht der benutzerdefinierten Felder klickt man dafür auf das Zahnrad rechts neben dem gewünschten Feld und wählt „Konfigurieren“. Dort trägt man die Optionen des Feldes ein und wählt ggf. einen Standardwert aus.

Möchte man das Feld zu einem Pflichtfeld machen, kann man dies über die Feldkonfiguration eines oder mehrerer Projekte erledigen.

Warum wird mein Feld nicht angezeigt?

Wenn ein benutzerdefiniertes Feld nicht angezeigt wird, kann das mehrere Ursachen haben. Mit dieser kurzen Checkliste sollte sich in den meisten Fällen die Ursache finden lassen:

  • Ist das Feld für dieses Projekt und diesen Vorgangstyp freigegeben?
  • Ist das Feld in der entsprechenden Bildschirmmaske (für dieses Projekt und diesen Vorgangstyp) eingefügt?
  • Wurde das Feld über die Feldkonfiguration dieses Projektes ausgeblendet?
  • Besitzt der Benutzer die Berechtigung, den Feldwert zu ändern? (z.B. werden einem Benutzer ohne die Berechtigung „Vorgang zuweisen“ die Felder „Autor“ und „Bearbeiter“ in der Bearbeiten-Maske nicht angezeigt)

Hinweis: seit kurzem steht Jira-Admins die Funktion „Wo ist mein Feld?“ zur Verfügung. Diese kann in einem Vorgang über das „Weitere Aktionen“ Menü aufgerufen werden und zeigt genau an, warum ein bestimmtes Feld nicht angezeigt wird.

Weitere Fehlerquellen

Die Einstellung „Standardwert“ klingt zunächst harmlos, stellt aber in der Praxis eine beliebte Fehlerquelle dar: ist einem Vorgangstyp z.B. ein benutzerdefiniertes Attribut „Kundennummer“ zugeordnet, aber in der Bildschirmmaske „Vorgang erstellen“ nicht mit eingebaut, wird beim Erstellen des Vorgangs automatisch der für dieses Feld eingestellte Standardwert verwendet.

Bei Pflichtfeldern rate ich meinen Kunden zu äußerst sparsamen Einsatz. Definiert man ein Feld als Pflichtfeld, muss man sich der Tatsache bewusst sein, dass  dieses Feld für alle gewählten Vorgangstypen und Projekte immer ein Pflichtfeld ist – auch schon beim Erstellen des Vorgangs. In diesem Fall muss man also sicherstellen, dass das Pflichtfeld entweder in allen Masken verfügbar oder ein Standardwert gesetzt ist.

30. Juli 2012 von Sebastian Höhne
Kategorien: Jira | Schlagwörter: , , | 16 Kommentare

Kommentare (16)

  1. Pingback: Jira FAQ: Projekte und Projektrollen • Sebastian Höhne • IT-Beratung und Training

  2. Pingback: Jira FAQ: Projekte einrichten • Sebastian Höhne • IT-Beratung und Training

  3. Hallo!

    Wie erstellt man ein Benachrichtigungsschema das mir direkt eingetragene Werte per Mail sendet. Habe leider mit den Gruppenfeld keine Erfolge erzielen können.

    mit besten Grüßen

    • Hallo Philipp,

      welche Werte sollen denn wann gesendet werden? Mit dem Benachrichtigungsschema werden standardmäßig nur Mails mit fest vorgegebenem Inhalt versendet (Vorgang wurde bearbeitet usw.). Wenn du den Inhalt der Mails verändern willst, musst du die entsprechencen Velocity-Dateien anpassen (siehe https://confluence.atlassian.com/display/JIRA/Customizing+Email+Content) – dabei hat man auch Zugriff auf das Issue-Objekt, damit sollten sich also auch einzelne Werte des Vorgangs in der Mail darstellen lassen (Anleitung für benutzerdefinierte Felder z.B. unter https://developer.atlassian.com/display/JIRADEV/Adding%20Custom%20Fields%20to%20Email).

      Grüße,
      Sebastian

      • Es soll durch das eröffnen einer Aufgabe, gewisse Felder per Mail weiter gesendet werden.
        zB.: Nutzer A füllt eröffnet eine Aufgabe, Abteilung B bekommt ein generiertes Mail mit Informationen aus der Aufgabe.
        Das heißt die Abteilung muss sich nicht mehr in Jira einloggen sondern bekommt alle Infos die benötigt werden per Mail und kann dann sofort darauf reagieren.
        So sind die Anforderungen an mich übergeben worden.

        Vielen Dank für die schnelle Antwort

        beste Grüße
        Philipp

        PS: führen sie Inhouse Schulungen in Österreich (Graz) durch?

      • Hallo Philipp,

        das geht prinzipiell, ist allerdings mit einigen Anpassungen verbunden und muss deswegen auch gut dokumentiert werden (da man nach jedem Jira-Update einige der Änderungen erneut durchführen muss). Vorgehen wäre prinzipiell so:

        • Ein eigenes E-Mail Template erstellen (Anleitung)
        • In diesen Templates die Felder einbauen, die gesendet werden sollen (Anleitung)
        • Ein eigenes Event anlegen (Globale Admin, System, Events), dabei das erstellte Email-Template auswählen.
        • Wenn es um den Vorgangstyp „Aufgabe“ geht: für diesen Vorgang eine Kopie des aktuell verwendeten Arbeitsablaufes machen und in denjenigen Projekten aktivieren, in denen die angepassten Mails versendet werden sollen.
        • Den neuen Arbeitsablauf öffnen und im Statusübergang „Create Issue“ als Folgefunktion das eben erstellte Event auslösen.
        • Ein neues Benachrichtigungsschema erstellen, dieses den gleichen Projekten wie beim Arbeitsablauf zuweisen.
        • In diesem Benachrichtigungsschema für das neue Event auswählen, welche Nutzer/Gruppen die Email erhalten sollen.

        Das sollte es gewesen sein… damit haben wir ein eigenes Email-Template mit benutzerdefinierten Felder erstellt, das Template einem Event zugewiesen, das Event dann in einem neuen Arbeitsablauf beim Erstellen einer Aufgabe ausgelöst, und beim Auslösen dieses Events im Benachrichtigungsschema die entsprechenden Personen als Empfänger angegeben. Ich habe es gerade mal selbst getestet und es hat gut funktioniert – ist allerdings wirklich etwas Einarbeitungsaufwand notwendig.

        Zun den Schulungen: schreib mir am besten mal eine Mail, wenn ihr da Interesse habt – Inhouse wird für Graz wegen der Reisekosten ziemlich teuer, wir können aber gerne auch einfach eine Schulung per Websession (Skype + TeamViewer o.ä.) machen.

        Grüße,
        Sebastian

  4. Hallo,

    gibt es eine Möglichkeit bei den Benutzerdefinierten Feldern (beispielsweise einer Auswahlliste) die Optionen über eine Datenbank laufen zu lassen.
    Sprich in einer Datenbank ist eine Werteliste und über ODBC o.ä. werden über einen Filter aus der Liste Werte entnommen und als Optionen eingetragen und aktualisiert?

    Guß,
    Finn

  5. Hallo Herr Höhne,

    ich habe eine Frage bezüglich der Benutzerdefinierten Felder. Ich bräuchte eigentlich ein eigenes Kommentarfeld… Folgenderaßen sieht mein Problem aus. Ich möchte gerne spezifische Kommentare (Analyse-Meldungen) ablegen, die nicht zwischen allen anderen Komentaren untergehen sollen. Ein Freitextfeld, in das immer wieder Text angehängt wird, ist aber auch keine Lösung, da ich die Person des Kommentars und das Erstellungsdatum wissen möchte. Was kann ich hierfür sinvollerweise verwenden? Oder wäre eine Kombination aus JIRA und Confluence hier sinnvoll/möglich. Analyse-Meldungen in Confluence ablegen und in das Jira Ticket einbinden?

    Viele Grüße,
    Steven

    • Hallo Herr Schellhaas,

      eine ideale Möglichkeit fällt mir dazu nicht ein, aber die verschiedenen Ansätze haben Sie ja schon beschrieben:

      • Bei der Jira-Variante könnte man ein Freitextfeld verwenden und in diesem Feld per Tabelle dafür Sorge tragen, dass die Meldungen strukturiert abgelegt werden (z.B. mit den Spalten: | Autor | Datum | Meldung | ). Für den Nutzer bedeutet das aber natürlich zusätzlichen Aufwand, da er für seine Meldung eine neue Zeile per Wiki-Syntax hinzufügen muss. Im Zweifel könnte man alternativ auch anhand der Änderungshistorie sehen, wann und von wem welcher Eintrag vorgenommen wurde – ist aber ebenfalls nicht besonders benutzerfreundlich.
      • Die zweite Möglichkeit mit Jira wäre, die Analyse-Meldungen in einen Untervorgang auszulagern: zu Ihrem normalen Vorgang erstellen Sie einen Untervorgang mit Namen (ggf. auch mit eigenem Vorgangstyp) „Analysemeldungen Vorgang-123“ und in dessen Kommentare kommen dann die Meldungen rein. Damit wären sie sauber getrennt, allerdings hat man dann eben auch immer 2 Vorgänge.
      • In Kombination mit Confluence könnte man pro Vorgang eine zugehörige Wikiseite anlegen und mit dem Vorgang verknüpfen. Die Analysemeldungen kommen dann in die Kommentare der Wikiseite, oder auch hier in eine strukturierte Tabelle (das würde sich in Confluence durch eine entsprechende Seitenvorlage einfacher umsetzen lassen und durch die intuitive Änderungshistorie könnte man Änderungen besser nachvollziehen als in Jira).
      • Je nach Anzahl der Vorgänge und Umfang der Analyse-Meldungen wäre es ggf. auch ausreichend, statt für jeden Vorgang eine eigene Wikiseite anuzlegen, eine einzige Übersichtsseite mit allen Analyse-Meldungen eines Projektes anzulegen. Darin befindet sich eine Tabelle mit den Spalten | Vorgang | Meldung | Datum | Autor | . In der „Vorgang“ – Spalte kann man per Makro „Jira-Issue“ leicht den entsprechenden Jira-Vorgang verlinken – dabei wird zusätzlich automatisch im Jira-Vorgang eine Verknüfung zu dieser Wikiseite erstellt. Damit hätte man eine große Tabelle mit allen Analyse-Meldugen eines Projektes, die von jedem betroffenen Jira-Vorgang aus verlinkt ist.

      Von meinem Standpunkt aus, finde ich die vierte Variante am besten: hier kann man relativ leicht beschreiben, was zu tun ist („Gehe in die Analyse-Übersichtsseite des Projektes im Wiki, verlinke den Vorgang und trage deine Analyse-Meldung ein“), ohne dass ggf. jeder Nutzer eine neue Wikiseite erstellen muss.

      Beste Grüße,
      Sebastian Höhne

  6. Hallo Sebastian, ich habe einen eigenen vorgangstypen erstellt mit darunterliegenden benutzerdefinierten Feldern. Nun möchte ich diese gerne exportieren über den jira xporter. Wie kann ich nun meine benutzerdefinierten Felder aufrufen? Bei den vorgegebenen Typen ging das ja recht simpel: Priorität ließ sich über ${priority} aufrufen. Wie ist das nun wenn mein eigenes Feld z.B. Sollwert heißt??? Kann ich es dann mit ${Sollwert} aufrufen?
    Liebe Grüße,
    Diana

  7. Hi Sebastian,

    erstmal vielen Dank für die zahlreichen Informationen, die du hier preis gibst. (y)

    Eine Frage habe ich jedoch noch: Ich habe ein Benutzerdefiniertes Feld „Abgrenzungen“, dieses möchte ich unter der „Beschreibung“ anzeigen lassen, ich habe jedoch bisher keine Möglichkeit gefunden, die Reihenfolge zu definieren – geht das überhaupt?

    • Nachtrag: Ich meine auf der Ticket-Seite, nicht auf einem Screen-Overlay ;-)

      • Hi Tino,

        für die Erstellen- und Bearbeiten-Masken geht das, für die normale Vorgang-Anzeigen Maske aber leider nur sehr eingeschränkt. Man kann zwar benutzerdefinierte Felder in diese Maske reinholen, allerdings werden die Felder fast immer automatisch angeordnet.

        Ausnahme: man verwendet in der Vorgang-Anzeigen Maske mindestens zwei Tabs und in jedem Tab ist mindestens ein benutzerdefiniertes Feld (Typ Text- oder Auswahlfeld) enthalten, welches jeweils einen ausgefüllten Wert hat. Nur in diesem Fall werden die benutzerdefinierten Felder in Tabs direkt überhalb der Beschreibung angezeigt.

        In der Praxis ist das aber für Nutzer manchmal eher verwirrend, weil manchmal Tabs angezeigt werden und manchmal nicht (je nachdem, ob Feldwerte in diese Felder eingetragen sind oder nicht).

        Also: nein, das geht in der Praxis eher nicht.

        Grüße,
        Sebastian

      • Hi Sebastian,

        ich hatte es befürchtet … DANKE für die schnelle und ausführliche Antwort.
        Da muss Atlassian nachbessern denke ich … ich habe nämlich ein „Wiki-artiges“ custom field und das wird oben bei den „Details“ angezeigt … sieht ziemlich unübersichtlich aus, wenn da viel drin steht :-(

        LG
        Tino

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert


feedback