Workflow

Wir werden anhand eines Beispiels lernen, wie man benutzerdefinierte Anwendungen erstellt. Wir entwickeln eine einfache Bug-Tracking-Anwendung. Wir gehen von zwei Teams aus: Entwickler – sie beheben Fehler – und QA (kurz für Qualitätssicherung) – sie testen die von den Entwicklern vorgenommenen Korrekturen. Wir modellieren den folgenden Bug-Workflow:

In einfachen Worten ausgedrückt bedeutet das Diagramm:

Wenn ein Fehler gemeldet wird, befindet er sich im Status „Neu“.
Die Qualitätssicherung prüft den Fehler. Handelt es sich nicht um einen Fehler, wird der Fehlerstatus auf „Geschlossen“ gesetzt; andernfalls auf „ Verifiziert“.
Ein von einem Entwickler als behoben bestätigter Fehler wird in den Status „Behoben“ verschoben .
Die Korrektur wird anschließend von der Qualitätssicherung getestet. Schlägt der Test fehl, wird der Fehler auf „Wieder geöffnet“ gesetzt; andernfalls auf „Geschlossen“.
Ein erneut geöffneter Fehler, der vom Entwickler behoben wurde, wird in den Status „Behoben“ verschoben.

Jede Blase repräsentiert eine Phase im Lebenszyklus eines Fehlers, jeder Pfeil eine Aktion des Endbenutzers. Neben jedem Status ist das zuständige Team angegeben. Ein Fehler kann nicht direkt von einem Status in einen anderen wechseln, z. B. nicht von „ Neu“ zu „ Behoben“.

Wir selbst nutzen eine eigene Bugtracking-Anwendung, die jedoch deutlich mehr Status anzeigt, um beispielsweise zu dokumentieren, ob ein Testfall vorhanden war, ob die Dokumentation aktualisiert oder ein neuer Testfall hinzugefügt wurde. Sie können den Workflow beliebig komplex oder einfach gestalten. Fürs Erste bleiben wir aber bei dem oben beschriebenen einfachen Workflow.

Erstellen einer App

Um eine App zu erstellen, gehen Sie zu HauptmenüAdministratorBenutzerdefinierte AppsApps und klicken Sie auf HinzufügenSie sehen ein Formular mit vielen Registerkarten. Wir werden jede Registerkarte im Folgenden erläutern.

Die Registerkarte „Basis“

Dieser Tab definiert einige grundlegende Eigenschaften der App. Darüber hinaus steuert er auch bestimmte Verhaltensweisen der App.

Name	Der Name Ihrer App. Hier wird „Bug“ stehen
Plural	Die Mehrzahlform des Namens.
Erster Zessionar	Wählen Sie den Benutzer aus, der neuen Instanzen automatisch zugewiesen werden soll.
App-Client erforderlich	Standardmäßig ist der Ersteller eines App-Elements auch dessen Anforderer. Es kann jedoch Fälle geben, in denen Sie eine App im Namen einer anderen Person erstellen und Benachrichtigungen und Updates an diese Person und nicht an den Ersteller senden möchten. In unserer App sollen unsere Support-Mitarbeiter Fehler im Namen eines Kunden melden können, Updates sollen aber direkt an den Kunden gesendet werden. Daher aktivieren wir diese Option. Ist sie aktiviert, wird beim Erstellen einer neuen App-Instanz das Feld „ Anforderer“ angezeigt
Verfallsdatum	Diese Option legt fest, ob das Fälligkeitsdatumfeld beim Hinzufügen/Bearbeiten eines App-Elements aktiviert oder deaktiviert wird. Da wir das Fälligkeitsdatumfeld nicht verwenden möchten, aktivieren wir diese Option.
Priorität verwenden	Diese Option legt fest, ob das Prioritätsfeld beim Hinzufügen/Bearbeiten eines App-Elements aktiviert oder deaktiviert wird. Da wir das Prioritätsfeld nicht verwenden möchten, aktivieren wir diese Option.
Ist Zeit erlaubt?	Ob die Zeiterfassung für das App-Element erlaubt sein soll. Wir möchten, dass unsere Entwickler und unser QA-Team die Zeit erfassen, daher aktivieren wir diese Option.
Ist es vom Kunden initiierbar?	Ob Sie möchten, dass Ihre Kunden neue Instanzen erstellen. Wir möchten, dass unsere Kunden Fehler melden, daher aktivieren wir diese Option.
Beschreibung	Eine kurze Beschreibung Ihrer App.
Follower	Wählen Sie die Standard-Follower aus. Follower erhalten Benachrichtigungen bei Neuzuweisungen, Statusänderungen oder neuen Kommentaren.
Aktiv	Ob Sie Ihre App aktivieren oder deaktivieren möchten. Wenn Sie sie als inaktiv markieren, werden bestehende Instanzen dieser App nicht gelöscht.

Die Registerkarte „Staaten“

Dieser Tab definiert die Zustände der App. Sie können hier auch den Start- und Endzustand im Workflow markieren. Wir haben alle Zustände unseres Bug-Workflows aufgelistet.

Startzustand	Wenn ein App-Element erstellt wird, wird es in diesen Status versetzt. In unserem Fall ist das der Status „Neu“.
Endzustand	Wenn ein App-Element diesen Status erreicht, gilt der Prozess als abgeschlossen. In unserem Fall ist er „Geschlossen“.

Die Registerkarte „Workflow“

Dieser Tab definiert alle Pfeile im Workflow-Diagramm. Jeder Pfeil repräsentiert eine Endbenutzeraktion. Weitere Informationen zur Verwendung finden Sie später in der Dokumentation.

Aktion	Der Name für die Aktion. Dieser wird in Aktionsmenüs für Bugs verwendet.
Aus	Der Staat, von dem der Pfeil ausgeht.
Zu	Der Zustand, in dem der Pfeil endet. Sobald die Aktion ausgeführt wurde, wird unser Fehler in diesen Zustand versetzt.
Zuweisen an	Der Benutzer, dem der Workflow nach Ausführung der Aktion zugewiesen wird. Die Eingabeaufforderung in der Rolle „Entwickler“ bedeutet, dass dem Benutzer, der die „Überprüfen“ für den Fehler durchführt, eine Liste von Entwicklern angezeigt wird, aus der er den neuen Bearbeiter auswählen kann.
Aktion Benutzer zulassen	Legt fest, ob diese Aktion von einem Benutzer ausgeführt werden kann. In manchen Fällen ist es nicht erwünscht, dass Endbenutzer diese Aktion ausführen. Beispielsweise werden in Helpdesk-Systemen Tickets, auf die nicht reagiert wird, nach einigen Tagen Inaktivität automatisch geschlossen.

Die Registerkarte „Trigger“

Mithilfe von Triggern können Sie Celoxis anweisen, Zustandsübergänge durchzuführen, wenn es eine E-Mail vom Anforderer empfängt.

In unserer Bug-Tracking-App benötigen wir keine Auslöser. Betrachten wir jedoch beispielsweise diesen Helpdesk-Workflow . Im Fall der Helpdesk-App ist der Anfragende die Person, die eine Frage gestellt hat. Wenn

Das

Person antwortet über

E-Mail

Wir möchten, dass das Ticket automatisch in den „Ungelöst“ , damit es dem Support-Team zur Kenntnis gebracht wird. Anders ausgedrückt: Wir möchten, dass die Wiederöffnungs- Übergänge erfolgen. In diesem Fall würden wir unsere Auslöser wie folgt definieren:

Registerkarte „Landesmanager“

Ein Statusmanager ist ein Benutzer, der als Manager fungiert, wenn sich eine App in einem bestimmten Status befindet. Er wird benachrichtigt, wenn sich etwas an einem Element in diesem Status ändert. In unserem Beispiel unten ist Mark der QA-Manager und somit für die Status „Neu“ und „Behoben“ verantwortlich, in denen das QA-Team arbeitet.

Sie können Statusmanager auf Projektebene überschreiben, wenn die Person, die diesen Status verwaltet, eine andere ist.

Wie geht es weiter?

Wir haben eine benutzerdefinierte App für unseren Bug-Workflow erstellt. Im nächsten Kapitel werden wir dem Bug einige benutzerdefinierte Felder hinzufügen.