22 Arbeiten mit Custom Fields in Jira

In Jira können benutzerdefinierte Felder (Custom Fields) verwendet werden, um Vorgänge projektspezifisch oder organisationsweit um zusätzliche Informationen zu erweitern. Sie ermöglichen eine flexible Anpassung der Vorgangsmasken an individuelle Prozesse und Informationsbedarfe.

Dokumentation zu Custom Fields

22.1 Zweck und Einsatz von Custom Fields

Standardfelder wie Zusammenfassung, Beschreibung oder Status reichen in vielen Fällen nicht aus, um alle relevanten Informationen eines Vorgangs zu erfassen. Mit Custom Fields lassen sich projektspezifische Eigenschaften wie „Kunde“, „Prioritätscode“, „Abnahmedatum“ oder „Verantwortlicher Fachbereich“ hinzufügen.

Typische Einsatzszenarien:

• Erfassung projektspezifischer Metadaten
• Filterung und Sortierung nach individuellen Kriterien
• Steuerung von Prozessen per Automation oder Workflow-Bedingungen
• Reporting und Auswertung über Jira Query Language (JQL)

22.2 Feldtypen

Jira bietet eine Vielzahl an Feldtypen für Custom Fields, darunter:

• Textfelder (einzeilig, mehrzeilig)
• Auswahllisten (einfach oder mehrfach)
• Datum/Zeit-Felder
• Zahl- oder Prozentfelder
• Benutzer- und Gruppenfelder
• Checkboxen, Radiobuttons
• Felder für Projektverknüpfungen, URLs, Versionen, Komponenten

Plugins und Apps wie ScriptRunner oder ProForma erweitern die verfügbaren Typen erheblich.

22.3 Verwaltung von Custom Fields

22.3.1 Erstellen eines Custom Fields

1. Administration → Issues
2. Im Bereich Fields → Custom Fields
3. Add Custom Field auswählen
4. Feldtyp wählen → Next
5. Namen und Beschreibung vergeben
6. Optional: Standardkonfiguration vornehmen
7. Auswahl der Screens, auf denen das Feld erscheinen soll → Create

22.3.2 Bearbeiten eines Custom Fields

1. In der Liste Custom Fields das gewünschte Feld → Configure
2. Optionen wie Beschreibung, Konfiguration, Optionen (bei Auswahlfeldern) anpassen
3. Ggf. Feldkontext ändern (s.u.)

22.3.3 Löschen eines Custom Fields

1. Custom Fields → Delete beim gewünschten Feld
2. Bestätigung notwendig
3. Hinweis: Alle Daten in diesem Feld gehen unwiderruflich verloren

22.4 Feldkontexte

Custom Fields können mit einem oder mehreren Projekten und Issue Types verknüpft werden. Diese Kontexte bestimmen:

• Wo das Feld sichtbar ist
• Welche Werte auswählbar sind (z. B. Optionen in einer Select-Liste)

Ein Kontext kann auf ein einzelnes Projekt oder global wirken. Kontextspezifische Konfigurationen erlauben es, dass ein Feld je nach Projekt unterschiedliche Werte oder Sichtbarkeiten hat.

Beispiel:

• Projekt A: Auswahlfeld „Kunde“ mit den Optionen A1, A2, A3
• Projekt B: dasselbe Feld, aber mit Optionen B1, B2, B3

22.5 Performance-Überlegungen

Eine große Anzahl ungenutzter oder falsch konfigurierter Custom Fields kann zu Performance-Problemen führen:

• Verlangsamung der Indexierung
• Beeinträchtigung bei JQL-Suchen
• Komplexe Workflows durch überladenes Feldlayout

Empfehlungen:

• Reduzierung der Felder durch Kontexte
• Vermeidung globaler Felder, wenn nicht nötig
• Regelmäßige Prüfung auf nicht verwendete Felder

22.6 Felder und Screens

Custom Fields müssen einem oder mehreren Screens zugewiesen werden, um sichtbar und editierbar zu sein. Ein Feld ohne Screen-Zuweisung ist zwar technisch vorhanden, aber nicht nutzbar.

Typische Screens:

• Create Issue Screen
• Edit Issue Screen
• View Issue Screen

22.7 Einschränkungen und Best Practices

• Einige Feldtypen (z. B. Cascading Select) sind nicht in allen Kontexten vollständig nutzbar
• Feldnamen sollten eindeutig und sprechend gewählt werden
• IDs von Custom Fields sind systemintern und können nicht geändert werden
• Namensänderungen haben keine Auswirkung auf JQL-Referenzen (diese verwenden customfield_xxxxx)

22.8 Sichtbarkeit und Bearbeitbarkeit von Custom Fields – Berechtigungsaspekte

22.8.1 Screen-Zuweisung als Sichtbarkeitsfilter

Ein Custom Field ist nur sichtbar und nutzbar, wenn es einem oder mehreren Screens zugewiesen wurde:

• Create Issue Screen: Sichtbar beim Anlegen eines Vorgangs
• Edit Issue Screen: Sichtbar beim Bearbeiten
• View Issue Screen: Sichtbar bei der Anzeige

Wichtig: Fehlt die Zuweisung, ist das Feld für Benutzer unsichtbar – auch wenn es existiert.

22.8.2 Feldkontexte zur Einschränkung auf Projekte und Issue Types

Über Field Contexts lässt sich festlegen:

• In welchen Projekten ein Feld überhaupt zur Verfügung steht
• Für welche Issue Types es gilt

Ein Feld, das keinem Kontext entspricht, wird nicht angezeigt – auch dies wirkt wie eine Zugriffssteuerung.

22.8.3 Feldkonfigurationen mit *Field Configuration Schemes

Hier lässt sich steuern:

• Ob ein Feld required (Pflichtfeld) ist
• Ob ein Feld hidden (versteckt) ist
• Ob ein Feld read-only ist

Diese Konfigurationen gelten projekt- und issuetype-spezifisch und ermöglichen somit gezielte Einschränkungen.

Beispiel:

• Ein Feld „Abnahmedatum“ ist im Projekt A sichtbar und bearbeitbar
• Im Projekt B ist es ausgeblendet (hidden)

22.8.4 Workflow-abhängige Einschränkungen

Über Conditions in Workflows kann die Bearbeitbarkeit einzelner Felder indirekt eingeschränkt werden:

• Transition Screens enthalten definierte Felder
• Conditions steuern, ob eine Transition – und damit das Feld – überhaupt sichtbar ist (z. B. nur für bestimmte Gruppen oder Rollen)

22.8.5 Globale Berechtigungen und Projektrollen

Die Anzeige von Feldern wird nicht direkt durch Permission Schemes gesteuert. Aber:

• Wenn ein Benutzer keine Berechtigung zum Bearbeiten eines Vorgangs hat, kann er auch kein Custom Field darin bearbeiten
• Felder, die in Workflows oder Automatisierungen verwendet werden, können Einschränkungen enthalten, z. B. nur Benutzer in Rolle „Fachbereich“ darf Feld X bearbeiten