Flux de travail
Nous allons apprendre à créer des applications personnalisées à travers un exemple. Nous allons développer une application simple de suivi des bogues. Nous supposerons la présence de deux équipes : les développeurs, qui corrigent les bogues, et l’équipe d’assurance qualité (AQ), qui teste les corrections apportées par les développeurs. Nous modéliserons le flux de travail de gestion des bogues suivant :
En termes simples, le diagramme se traduit par :
- When a bug is reported, it is in the New state.
- QA verifies the bug. If it is not a bug, the bug moves to Closed; else to the Verified state.
- A verified bug fixed by a developer moves to the Fixed state.
- The fix is then tested by QA and the bug moves to Reopened, if test fails; or Closed, if the test passes.
- A Reopened bug fixed by the developer moves to the Fixed state.
Each bubble is represents a stage in the bug life-cycle while each arrow an end-user action. Next to each state we have defined the team responsible for it. Also, note that there is no way for a bug to move from any state directly to any other state e.g. A bug cannot move directly from New to Fixed
Nous utilisons nous-mêmes notre propre application de suivi des bogues, mais elle comporte beaucoup plus d'états pour indiquer la présence d'un cas de test, la mise à jour de la documentation, l'ajout d'un cas de test, etc. De même, vous pouvez rendre le flux de travail aussi complexe ou simple que vous le souhaitez. Pour l'instant, concentrons-nous sur le flux de travail simple que nous avons évoqué précédemment.
Création d'une application
Pour créer une application, rendez-vous sur Menu principalAdministrateurApplications personnaliséesApplications et cliquez sur AjouterVous verrez un formulaire comportant plusieurs onglets. Nous allons les détailler un par un ci-dessous.
L'onglet Basique
Cet onglet définit certaines propriétés de base de l'application. De plus, il contrôle également certains comportements de l'application.
| Nom | Nom de votre application. Nous indiquerons « Bug » ici. |
| Pluriel | Le pluriel du nom. |
| Initial Assignee | Sélectionnez l'utilisateur qui sera automatiquement affecté aux nouvelles instances. |
| App Client Reqd | Par défaut, le créateur d'un élément d'application en est également le demandeur. Cependant, il peut arriver que vous souhaitiez lancer une application pour le compte d'une autre personne et que les notifications et mises à jour lui soient envoyées, et non au créateur. Dans notre application, nous souhaitons que nos agents de support puissent signaler des bogues pour le compte d'un client, mais que les mises à jour soient envoyées à ce dernier. C'est pourquoi nous activons cette option. Une fois activée, un « Demandeur » apparaît lors de la création d'une nouvelle instance d'application. |
| Use Due Date | This option determines whether to enable or disable the due date field on the Add/Edit app item. Since we don't want to use the Due Date field, we check this option. |
| Use Priority | This option determines whether to enable or disable the Priority field on the Add/Edit app item. Since we don't want to use the Priority field, we check this option. |
| Le temps est-il autorisé ? | Autoriser ou non l'enregistrement du temps passé sur l'élément d'application. Nous souhaitons que nos développeurs et notre équipe d'assurance qualité enregistrent leur temps de travail ; nous avons donc coché cette option. |
| Is Client Initiable | Indiquez si vous souhaitez que vos clients puissent créer de nouvelles instances. Nous souhaitons que nos clients signalent les bogues, c'est pourquoi nous cochons cette option. |
| Description | Une brève description de votre application. |
| Abonnés | Sélectionnez les abonnés par défaut. Ces abonnés recevront des notifications en cas de réaffectation, de changement de statut ou de nouveaux commentaires. |
| Actif | Indiquez si vous souhaitez activer ou désactiver votre application. La désactiver ne supprimera pas les instances existantes de cette application. |
L'onglet États
Cet onglet définit les états de l'application. Vous pouvez également indiquer les états de début et de fin du flux de travail. Nous avons répertorié tous les états de notre flux de travail de correction de bogues.
| État initial | Lorsqu'un élément d'application est créé, il passe à cet état. Dans notre cas, il s'agit de « Nouveau ». |
| État final | Lorsqu'un élément d'application atteint cet état, le processus est considéré comme terminé. Dans notre cas, il est fermé. |
L'onglet Flux de travail
This tab defines all the arrows in the workflow diagram. Each arrow represents an end-user action. We shall see more about its usage later on in the documentation.
| Action | Nom de l'action. Ce nom sera utilisé dans les menus d'actions pour les bogues. |
| Depuis | L'État d'origine de la flèche. |
| À | L'état où la flèche se termine. Une fois l'action effectuée, notre bogue passera à cet état. |
| Attribuer à | L'utilisateur auquel le flux de travail sera attribué une fois l'action effectuée. L'invite dans le rôle : Développeur indique que l'utilisateur effectuant la vérification du bogue se verra présenter une liste de développeurs parmi lesquels choisir le nouvel auteur de la tâche. |
| Action Allow User | Détermine si cette action peut être effectuée par un utilisateur. Dans certains cas, nous ne souhaitons pas que les utilisateurs finaux effectuent cette action. Par exemple, dans les systèmes de support technique, les tickets restés sans réponse sont automatiquement fermés après quelques jours d'inactivité. |
L'onglet Déclencheurs
Using triggers you can tell Celoxis to perform state transitions when it receives an email from the requestor.
In our bug tracking app, we don't need any triggers. However, let's take this help desk workflow for example. In case of the help desk app, the requestor will be the person who asked a question. When
that
person replies via
, we would want the ticket to be automatically moved to the Unresolved state as then it would be brought to the attention of the support team. In other words, we would want the Reopen transitions to happen. In this case, we would be defining our triggers like this:
L'onglet Gestionnaires d'État
A state managers is a user who is treated as a Manager when an app is in a particular state. They are notified when things happen to an item in this state. In our example below, Mark is the QA manager, so he is responsible for the New and Fixed states where the QA team is supposed to do work.
You can override state managers at a project level if the person managing that state is different.
Et ensuite ?
Nous avons créé une application personnalisée pour notre flux de travail de gestion des bogues. Dans le chapitre suivant, nous ajouterons des champs personnalisés au bogue.