.svg)
Passen Sie die Optionen für ein ausgewähltes Feld nach Arbeitstyp an — im gleichen Raum — Ein Showcase ohne Code Behaviours Builder
Erfahre, wie du mithilfe von No Code Behaviours ausgewählte Feldoptionen nach Arbeitstyp im selben Jira-Bereich anpassen kannst, ohne Felder zu duplizieren.
2013: Doktor der Informatik. 2021: Master of Business Administration (MBA). 13 Jahre Erfahrung im Projektmanagement.
Die Feldkontexte von Jira Cloud sind flexibel, aber in einem bestimmten Fall stoßen sie an ihre Grenzen: Sie variieren die Optionen eines Single-Select-Felds je nach Arbeitstyp innerhalb desselben Bereichs. Hier erfährst du, was fehlt — und wie du es umgehen kannst, ohne Felder zu duplizieren.
Der Anwendungsfall
Im Bereich Vorlagen verwenden wir ein benutzerdefiniertes Feld Impact mit zwei Arbeitstypen:
Ein Feld, ein Leerzeichen, zwei Optionssätze — abhängig vom Arbeitstyp.
Warum löst die native Konfiguration das Problem nicht?
Mit Jira Cloud kannst du bestimmten Bereichen und Arbeitstypen einen Feldkontext zuweisen und innerhalb dieses Kontextes alternative Optionen definieren. Das ist in der Regel ausreichend — bis du zwei Kontexte desselben Feldes innerhalb desselben Bereichs benötigst, aufgeteilt nach Arbeitstypen. Diese Kombination wird nicht unterstützt. Atlassian hat es unter verfolgt JRACLOUD-6851 lange Zeit, immer noch markiert Im Gange. Dieselbe Einschränkung ist der Grund, warum die Auswahllistenoptionen innerhalb eines einzelnen Projekts nicht nach Arbeitstyp eingeschränkt werden können.
Der übliche Workaround — und warum es weh tut
Die meisten Teams teilen das Feld in zwei Teile auf:
- Wirkung — Workstream
- Wirkung — Aufgabe
Es funktioniert technisch und Atlassians eigener Tracker listet es als empfohlene Problemumgehung auf. Aber du verwaltest jetzt zwei Felder für das, was aus geschäftlicher Sicht ein Konzept ist:
- doppelter Verwaltungsaufwand
- JQL und Dashboards, die beide Felder vereinen müssen
- Berichterstattung, die zwei Spalten abgleichen muss
- Endbenutzer sind sich nicht sicher, welche Auswirkung ist der „echte“
Sie haben ein sauberes Datenmodell gegen eine maßgeschneiderte UX eingetauscht. Sie möchten selten zwischen diesen wählen.
Ein Feld mit einer Verhaltensebene beibehalten
Wenn die Kontextlogik in eine Verhaltensebene übergeht, bleibt das Feld einzeln und beide Ziele überleben. Hier ist ein Beispiel-Setup mit Behaviours Builder von VIP.LEAN, kein Code involviert.
- Definiere den ersten Kontext: Space = Vorlagen, Arbeitstyp = Workstream
- Definiere den zweiten Kontext: Space = Vorlagen, Arbeitstyp = Aufgabe
Jetzt fügen Sie für jeden Kontext die Aktionen hinzu, die im Zielfeld ausgeführt werden sollen: Auswirkung.
- Optionen für Kontext 1 festlegen
- Optionen für Kontext 2 festlegen
- Ergebnis: Die verfügbaren Optionen in Auswirkung folgen Sie nun dem Arbeitstyp im gleichen Raum mit einem darunter liegenden Feld.
Wenn es sich auszahlt
Für die meisten Felder reichen native Kontexte aus. Eine Verhaltensebene verdient ihren Lebensunterhalt, wenn Sie Folgendes benötigen:
- ein Feld für mehrere Arbeitstypen mit unterschiedlichen Optionen pro Typ
- Sichtbarkeit oder erforderliche Logik, abhängig von Kombinationen, die Jira nicht nativ ausdrücken kann
- übersichtliches Reporting und trotzdem jedem Arbeitstyp ein maßgeschneidertes Formular
Das ist die Lücke JRACLOUD-6851 lässt offen — und wo eine Verhaltensebene leise die Arbeit erledigt.
Start your free trial and get up to
35% discount!
.svg)
