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: , , | 27 Kommentare

Kommentare (27)

  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

  8. Kann man einzelne Felder exklusiv nur für eine bestimmte Projektrolle sichtbar machen?

    • Hallo,

      nein, standardmäßig geht das leider nicht – wer einen Vorgang sehen darf, darf auch alle im Vorgang befindlichen Felder sehen. Allerdings gibt es Plugins wie Secure Fields, mit denen das für benutzerdefinierte Felder möglich ist. Zu beachten ist allerdings, dass es sich dabei um neue, zusätzliche Feldtypen handelt – man kann damit also nicht nachträglich bestehende Felder ausblenden.

      Beste Grüße,
      Sebastian Höhne

      • Hallo,

        das geht allerdings mit dem Plugin „Field Security for Jira“ von der Firma Quisapps. Dort kann man Schemata erstellen, welche die Berechtigung auf einzelnen Feldern enthalten und welche auch nachträglich den Zugang und die Sichtbarkeit einschränken. Diese Schemata werden dann pro Projekt verwendet, genau wie alle anderen Schemata auch.

        Viele Grüße,
        Jens

  9. Hallo Sebastian,
    einen lieben Dank, dass du hier dein Wissen teilst – und die Kommentare seit Jahren weiter Leben :)
    Dann reihe ich mich auch einmal ein.

    Besteht die Möglichkeit für ein bestimmtes Projekt beim Erstellen von Bugs das Beschreibungs-Feld mit einem Teamplate zu versehen?
    Ich suche nach einer Möglichkeit Bugs zu standardisieren, um Klarheit zu schaffen.

    Vielen Dank an dich,
    Ivana

    • Hallo Ivana,

      sehr gerne. :) Ja, das geht auf mehreren (teils aber etwas umständlichen) Wegen. Mit Bordmitteln hast du hier eine Anleitung von Atlassian, mit der du in der Feldkonfiguration (dieses Projektes und dem Vorgangstyp Bug) ein kleines JavaScript mit dem Standardtext einbauen kannst. Die mächtigste, aber auch komplexeste Möglichkeit hast du mit dem Plugin ScriptRunner und diesem Beispiel. Ansonsten gibt es auch noch das Plugin Default Values for Create Issue Screen, welches anscheinend genau deine Anfoderung umsetzt. Sollte im Vergleich zu den anderen Varianten einfacher umsetzbar sein, habe ich aber selber noch nie verwendet.

      Viele Grüße,
      Sebastian

  10. Hallo Sebastian,

    vielen Dank für all die Tipps und Informationen die Du hier zur Verfügung stellst.

    Eine Frage: Kann ich ein benutzerdefiniertes Feld erstellen, das in der Vorgangsansicht nicht oben unter den „Details“ angeordnet ist, sondern unterhalb der „Beschreibung“ auf einer Ebene mit mit „Details“, „Besschreibung“, „Anhänge“ usw. Also eine Überschrift z.B. „Links“ mit untergeordneten Feldern.

    Ich freue mich auf Deine Antwort :-)
    Vielen Dank schon mal!

    Herzliche Grüße
    Martina

    • Hallo Martina,

      mit Bordmitteln ist das leider nicht möglich. Alle benutzerdefinierten Felder werden in der Vorgangsansicht automatisch bei Details (Text- und Auswahlfelder), Personen (Personen- und Gruppenauswahlfelder) oder Daten (Datums- und Zeitauswahlfelder) eingeordnet. Nur die Reihenfolge der benutzerdefinierten Felder kann man per Bildschirmmaske festlegen. Evtl. ist das mit einem Theming-Plugin möglich (z.B. Refined https://marketplace.atlassian.com/apps/1216711) – da kann ich aber leider nichts genaueres dazu sagen.

      Viele Grüße,
      Sebastian

  11. Hallo Sebastian.

    ich habe folgendes Problem:
    Ich habe in einem Projekt einen Anfragetypen (Beschaffung), hier habe ich mehrere Untertypen ( Laptop, Handy, etc.).
    Bei Laptop habe ich ein benutzerdefiniertes Feld (Bildschirmgröße als Drop-Down Auswahl) drin.
    Hier ist der Standardwert 14″ gesetzt.

    Wenn ich jetzt unter dem Untertypen Handy das Feld Bildschirmgröße nicht hinzufüge, erscheint es im Ticket trotzdem mit dem Standardwert Bildschirmgröße 14″, obwohl man es im Beschaffungsportal bei Handy gar nicht zu Auswahl hatte.
    Nur wenn ich keinen Standardwert setze (Standardwert auf „Keine“), zieht es diese Option bei Handy nicht mit.

    Kann man das irgendwie einstellen, wenn man einen Standardwert setzt, dass er bei anderen Untertypen nicht mitgezogen wird?

    Grüße Timo

    • Hallo Timo,

      ja, das geht. In dem Menü, in dem du den Standardwert gesetzt hast, kannst du auch mehrere „Kontexte“ für dieses benutzerdefinierte Feld festlegen (siehe hier). Die Kontexte eines Feldes legen z.B. fest, für welche Projekte und Vorgangstypen dieses Feld zur Verfügung stehen soll und welche Feldwerte / Standardwert dort verwendet werden soll. Du hast jetzt den Standardkontext eingerichtet, der für alle Projekte / Vorgangstypen gilt. Dadurch wurde bei allen neu erstellten Vorgängen dieser Standardwert gesetzt.

      In dem benannten Menü kannst du weitere Kontext anlegen, jedem Kontext andere Projekte/Vorgangstypen zuweisen (Handy, Laptop…) und jeweils andere Werte / Standardwert verwenden. Aber wichtig: in allen Vorgängen, die seit dem Einrichten dieses Feldes bei euch erstellt wurden, ist jetzt der Wert 14″ eingetragen, auch wenn das Feld in den Bildschirmmasken gar nicht verwendet und das Feld daher dem Nutzer auch nicht angezeigt wird. In Filtern/Dashboards werden diese Vorgänge dann trotzdem als Treffer für 14″ angezeigt. Du musst du also ggf. nochmal aufräumen (d.h. Suche für Feld Bildschirmgröße ausführen und dann per Mehrfachänderung aus allen Vorgängen rauslöschen wo er nicht hingehört).

      Grüße,
      Sebastian

  12. Hallo

    kann man auch einen Dokumentenupload in den „benutzerdefinierten Feldern“ einfügen?

    Danke

    • Hallo Anne,

      das kommt darauf an – in der Data Center Variante gibt es das Plugin File Field, mit dem man benutzerdefinierte Upload-Felder erstellen kann. In der Cloud Variante gibt es das Plugin leider nicht. Die Frage wäre aber, was für eine Anforderung hinter dem zusätzlichen Upload-Feld steht, die über das normale Hochladen von Anhängen an einen Vorgang hinausgeht. Viele Anforderungen bezüglich Dateien (z.B. bessere Übersicht durch Labels, Revisionen) lassen sich mit Smart Attachments abbilden, das gibt es sowohl für Data Center als auch für die Cloud.

      Grüße,
      Sebastian

Schreibe einen Kommentar zu Diana Antworten abbrechen

Pflichtfelder sind mit * markiert


feedback