Erstellung mehrstufiger kaskadierender Felder in Jira Cloud: Ein No-Code-Ansatz

Das native Cascading Select-Feld von Jira bietet dir ein Elternteil und ein Kind in einem einzigen Feld. In dem Moment, in dem du eine dritte Ebene benötigst oder du möchtest, dass eine Auswahl ganz andere Felder ein- oder ausblenden soll, sind dir die nativen Optionen ausgegangen.

In diesem Artikel erfahren Sie, wie Sie das lösen können — anhand eines konkreten Beispiels können Sie Aktion für Aktion verfolgen.

Das Problem: Was Jira nativ nicht kann

Hier ist eine Anforderung, die in Teams, die Anfragen verwalten, ständig auftaucht:

„Wenn jemand eine Anfrage einreicht, möchte ich, dass sich das Formular an die Bedürfnisse anpasst — und ihm nicht eine Wand aus irrelevanten Feldern zeigt.“

Ein einfaches Beispiel könnte so aussehen:

• Auswahl Einrichtungen ist einfach — ein Folgefeld mit drei Standortoptionen. Auswahl IT-Ausrüstung öffnet ein überlappendes Feld (Gerätetyp) mit drei Geräten, jedes mit eigenen untergeordneten Optionen. Und wenn Laptop ausgewählt ist, erscheinen zwei zusätzliche Felder, unabhängig davon, welches Betriebssystem ausgewählt wurde.

Was Native Jira dir bietet

Die native Jira-Konfiguration kann einfache Fälle abdecken, aber dieses spezielle Muster erfordert ein dynamischeres Feldverhalten.

‍

Keines davon deckt das obige Szenario ab. Sie benötigen eine bereichsübergreifende Sichtbarkeitslogik — und dazu müssen Sie über das native Jira hinausgehen.

Die Lösung: Apps zum Feldverhalten

Verschiedene Marketplace-Apps können beim dynamischen Feldverhalten in Jira Cloud helfen.

Einige Tools bieten eine skriptbasierte Verhaltenslogik. Andere bieten eine No-Code- oder Low-Code-Schnittstelle, mit der Administratoren mithilfe von Triggern, Bedingungen und Aktionen Regeln erstellen können.

Für die exemplarische Vorgehensweise verwenden die Beispiele VIP.LEAN Behaviours Builder um die No-Code-Version dieses Musters zu demonstrieren.

Schritt 1: Das Verhalten erstellen

Der erste Schritt besteht darin, das Verhalten selbst zu erstellen — Sie geben ihm einen Namen, weisen ihm einen Kontext zu (für welchen Problemtyp und welches Projekt es gilt), legen einen Status fest und weisen einen verantwortlichen Benutzer zu.

Schritt 2: Die Aktionen erstellen

Hier lebt die eigentliche Logik. Jede Aktion definiert, wie sich ein Feld auf einem oder mehreren Jira-Bildschirmen verhalten soll. Sie kann beim Laden und/oder bei einer Änderung ausgelöst werden, sodass das Formular reagiert, unabhängig davon, ob die Seite gerade geöffnet wurde oder der Benutzer einen Wert geändert hat.

Bedingungen werden direkt beim Erstellen der einzelnen Aktionen erstellt. Sobald sie erstellt wurden, stehen sie in einer Dropdownliste für alle nachfolgenden Aktionen zur Verfügung — unabhängig von diesem Verhalten oder einem anderen. Hier wird es effizient: Sie definieren eine Bedingung einmal und verwenden sie dann so oft wie nötig, indem Sie sie mit der UND-/OR-Logik kombinieren.

Aktion 1 — Feld „Einrichtungen“ anzeigen

Bei der ersten Aktion wird das Feld Einrichtungen angezeigt, wenn der Benutzer im Feld Anforderungskategorie die Option Einrichtungen auswählt.

• Auslöser: Beim Laden + Beim Ändern
• Zustand: CON-19 — Anforderungskategorie = Einrichtungen
• Änderung: Sichtbarkeit der Einrichtungen einstellen = Ja

‍

Aktion 2 — Einrichtungen ausblenden

Jetzt brauchen wir das gegenteilige Verhalten.

Wenn die Anforderungskategorie leer ist oder der Benutzer IT-Ausrüstung ausgewählt hat, sollte das Feld Standort der Einrichtungen nicht sichtbar sein.

‍

Dies ist das Kernmuster: Dieselbe Bedingung, die ein Feld in Aktion 1 zeigte, hilft dabei, die entgegengesetzte Logik in Aktion 2 zu definieren. Eine Bedingung, zwei Jobs.

‍

Aktionen 3 und 4 — Gerätetyp

Das gleiche Muster gilt jetzt für das Feld Gerätetyp. Der Gerätetyp sollte nur angezeigt werden, wenn die Kategorie IT-Geräte lautet.

• Aktion 3: Gerätetyp anzeigen → CON-20: Anforderungskategorie = IT-Ausrüstung

‍

‍

• Aktion 4: Gerätetyp ausblenden → CON-18 ODER CON-19

Verbleibende Aktionen — Lieferadresse und Genehmigungsberechtigte

Jetzt gehen wir mit Lieferadresse und Genehmigern eine Ebene tiefer, diesmal basierend auf dem Wert für den Gerätetyp. Sie müssen nicht alle einzeln durchgehen — die Logik ist inzwischen dieselbe: eine Aktion zum Anzeigen, eine zum Ausblenden, Bedingungen aus dem Dropdown werden wiederverwendet.

Das Ergebnis

Nachdem alle Aktionen aktiviert sind, passt sich der Jira-Problembildschirm nun an, wenn der Benutzer eine Auswahl trifft.

Wenn der Benutzer Einrichtungen auswählt, wird ihm nur das Feld Standort der Einrichtungen angezeigt.

Wenn der Benutzer IT-Geräte auswählt, wird ihm Gerätetyp angezeigt.

Wenn sie dann Laptop auswählen, werden die Felder Lieferadresse und Genehmigende angezeigt.

Wenn sie ihre Meinung ändern und eine andere Kategorie auswählen, werden Felder, die nicht mehr zutreffen, ausgeblendet.

Was macht diesen Ansatz leistungsstark

Ein paar Dinge, die es wert sind, über das konkrete Beispiel hinaus mitzunehmen:

Ein Verhalten, volle Klarheit. Die gesamte Logik eines Formulars befindet sich an einem Ort. Leicht zu lesen, leicht an jemand anderen zu übergeben, später leicht zu erweitern.

Bedingungen sind Vermögenswerte. Jede Bedingung, die Sie erstellen, kann für all Ihre Aktionen und Verhaltensweisen wiederverwendet werden. Je mehr Sie bauen, desto weniger erstellen Sie von Grund auf neu.

Letzte Gedanken

Dynamische Formen sind einer der Bereiche, in denen native Werkzeuge den meisten Raum lassen. Das Muster hier lässt sich gut skalieren: mehr Felder, mehr Zweige, mehr Bedingungen — alles folgt derselben Struktur, ohne kompliziert zu werden.

Links:

Links:

• Kostenlose Testversion auf: Atlassian Marketplace
• Warum für das Verhalten in Jira Cloud kein Entwickler erforderlich sein sollte
• Passen Sie die Optionen für ein ausgewähltes Feld nach Arbeitstyp im gleichen Bereich an — kein Code Behaviours Builder Showcase
• Dynamisches Feldverhalten in das JSM-Kundenportal bringen

‍

‍