25 Beziehungen in JIRA: Screens und Workflows im Überblick

25.1 Screens, Screen Schemes und Layouts

Die visuelle Darstellung und Bearbeitbarkeit von Vorgängen (Issues) in JIRA wird durch ein mehrstufiges Schema gesteuert, das aus folgenden Komponenten besteht:

• Projekt: Enthält eine Menge von Issue Types, z. B. Bug, Task, Story. Jedes Projekt verwendet eigene Konfigurationen.
• Issue Type: Ein Vorgangstyp innerhalb eines Projekts. Jedem Issue Type wird ein eigener Issue Screen Scheme zugeordnet.
• Issue Screen Scheme: Ordnet den drei Operationen create, edit und view jeweils ein eigenes Screen Scheme zu.
• Screen Scheme: Verweist für jede Operation auf einen bestimmten Screen, der die tatsächliche Feldanordnung definiert.
• Screen: Besteht aus mehreren Tabs (Main, Details, etc.), die wiederum Felder enthalten.
• Felder (Fields): Bestimmen den Informationsgehalt eines Vorgangs. Standardfelder und benutzerdefinierte Felder können hier verwendet werden.

In der Cloud-Variante von JIRA wird zusätzlich das Konzept Issue Type Layout verwendet:

• Issue Type Layout: Definiert die Anordnung von Tabs, Feldern und Spalten (z. B. linke/rechte Seite) für einen bestimmten Issue Type.
• Screen Layout: Eine Detailstruktur innerhalb eines Layouts, die das visuelle Verhalten auf Tabs und Positionen herunterbricht.

• Ein Projekt enthält mehrere Issue Types.
• Jeder Issue Type verweist auf einen Issue Screen Scheme.
• Jeder Issue Screen Scheme enthält drei Screen Schemes für create, edit und view.
• Jeder Screen Scheme verweist auf einen Screen.
• Jeder Screen enthält mehrere Tabs.
• Jeder Tab enthält mehrere Felder.
• Das Layout des Screens kann über ein Issue Type Layout verfeinert werden.

Diese modulare Architektur ermöglicht eine präzise Kontrolle darüber, welche Felder wann und wie sichtbar oder editierbar sind.

25.2 Workflows, Workflow-Schemata und Statusübergänge

Die Prozesslogik in JIRA wird durch Workflows abgebildet, die definieren, wie sich ein Vorgang in einem Projekt von einem Status in den nächsten bewegt. Die wichtigsten Entitäten dabei sind:

• Projekt: Verwendet ein Workflow Scheme, das die Zuordnung von Workflows zu den einzelnen Issue Types des Projekts steuert.
• Workflow Scheme: Ordnet jedem Issue Type einen spezifischen Workflow zu.
• Workflow: Definiert eine gerichtete Zustandsmaschine mit Status (z. B. To Do, In Progress, Done) und Transitions (z. B. Start Progress).
• Transition: Verbindet zwei Status miteinander. Transitions enthalten:
  • Conditions: Bedingungen, die erfüllt sein müssen, damit eine Transition sichtbar ist (z. B. Nutzer muss Gruppenmitglied sein).
  • Validators: Validieren Eingaben während der Transition (z. B. Kommentar darf nicht leer sein).
  • Post Functions: Aktionen, die nach erfolgreichem Übergang automatisch ausgeführt werden (z. B. Setze Resolution, Sende Event).

• Jedes Projekt nutzt genau ein Workflow Scheme.
• Ein Workflow Scheme ordnet jedem Issue Type einen Workflow zu.
• Ein Workflow enthält mindestens einen Status und eine oder mehrere Transitions.
• Transitions verbinden Status miteinander und enthalten Conditions, Validators und Post Functions.
• Eine Transition verweist genau auf einen Zielstatus.

Diese Architektur ermöglicht es, für jeden Vorgangstyp im Projekt einen passenden Lebenszyklus zu definieren und fein granular zu steuern, wer wann welche Änderungen durchführen darf.