Flux de travail
Nous allons apprendre à construire des applications personnalisées à travers un exemple. Nous allons construire une application simple de suivi des bogues. Nous supposerons que nous avons deux équipes : Les développeurs - ils corrigent les bogues, et l'AQ (abréviation de Quality Assurance) - ils testent les corrections apportées par les développeurs. Nous allons modéliser le workflow de bugs suivant :
En français, le diagramme se traduit par :
- Lorsqu'un bogue est signalé, il est dans l'état Nouveau.
- L'AQ vérifie le bogue. Si ce n'est pas un bogue, le bogue passe à l'état Closed ; sinon à l'état Verified.
- Un bogue vérifié et corrigé par un développeur passe à l'état Fixed.
- La correction est alors testée par l'AQ et le bogue passe en mode Réouvert, si le test échoue ; ou Fermé, si le test réussit.
- Un bogue Réouvert corrigé par le développeur passe à l'état Corrigé.
Nous utilisons nous-mêmes notre propre application de suivi des bogues mais nous avons beaucoup plus d'états pour indiquer si un scénario de test était présent, si la documentation a été mise à jour, si un scénario de test a été ajouté, etc. De même, vous pouvez rendre le workflow aussi complexe ou simple que vous le souhaitez. Mais pour l'instant, restons sur le simple workflow dont nous avons parlé plus haut.
Création d'une application
Pour créer une application, allez à Menu supérieur ▸ ▸ Administrateur ▸ Personnaliser les applications ▸ Applis et cliquez sur Ajouter. Vous verrez un formulaire avec de nombreux onglets. Nous allons couvrir chaque onglet ci-dessous.
L'onglet Basique
Cet onglet définit quelques propriétés de base de l'application. De plus, il contrôle également certains comportements de l'application.
| Nom | Le nom de votre application. Nous allons mettre Bug ici. |
| Pluriel | Le nom au pluriel pour le nom. |
| Initialement affecté à | Sélectionnez l'utilisateur qui sera automatiquement assigné aux nouvelles instances. |
| Application du client requise | Par défaut, le créateur d'un élément d'application est également le demandeur de cet élément d'application. Cependant, il pourrait y avoir des cas où vous voudriez lancer une application au nom de quelqu'un d'autre et faire envoyer des notifications et des mises à jour à cette personne et non au créateur. Dans notre application, nous voudrions que nos agents de support puissent ouvrir des bogues au nom d'un client, mais nous voudrions que les mises à jour soient envoyées au client. Alors on l'allume. Lorsqu'il est activé, vous verrez un champ Requestor activé lors de la création d'une nouvelle instance d'une application. |
| Permet la journalisation du temps | Autoriser ou non le temps de journalisation sur l'élément de l'application. Nous aimerions que nos développeurs et l'équipe d'assurance qualité enregistrent le temps, c'est pourquoi nous cochons cette option. |
| Les clients peuvent initier cette appli. | Si vous voulez que vos clients créent de nouvelles instances. Nous aimerions que nos clients nous signalent les bogues, alors nous cochons cette option. |
| Description | Une brève description de votre application. |
| Followers | Sélectionnez les suiveurs par défaut. Les suiveurs recevront des notifications lorsqu'il y aura une réaffectation, un changement d'état ou de nouveaux commentaires. |
| Actif | L'activation ou la désactivation de votre application. Le fait de le marquer comme inactif ne supprimera pas les instances existantes de cette application. |
L'onglet Etats
Cet onglet définit les états de l'application. Vous pouvez également marquer les états de début et de fin dans le workflow. Nous avons listé tous les états dans notre workflow de bugs.
| Etat de démarrage | Lorsqu'un élément d'application est créé, il est déplacé dans cet état. Dans notre cas, c'est nouveau. |
| État final | Lorsqu'un élément de l'application passe à cet état, le processus est considéré comme terminé. Dans notre cas, il est fermé. |
L'onglet Workflow
Cet onglet définit tous les flèches dans le diagramme de flux de travail. Chaque flèche représente une action de l'utilisateur final. Nous verrons plus loin dans la documentation comment il est utilisé.
| Action | Le nom de l'action. Cela sera utilisé dans les menus d'action pour les bogues. |
| De | L'état d'où provient la flèche. |
| A | L'état où la flèche se termine. Une fois l'action effectuée, notre bug sera déplacé dans cet état. |
| Attribuer à | L'utilisateur auquel le workflow sera affecté après l'exécution de l'action. Prompt dans le rôle : Le développeur indique que l'utilisateur qui effectue l'action de vérification du bogue se verra présenter une liste de développeurs parmi lesquels choisir le nouvel attributaire. |
| Autoriser l’utilisateur | Détermine si cette action peut être effectuée par un utilisateur. Dans certains cas, nous ne voudrions pas que les utilisateurs finaux effectuent l'action. Par exemple, dans les systèmes de help desk, les tickets non réactifs sont automatiquement fermés après quelques jours d'inactivité. |
L'onglet Déclencheurs
Dans notre application de suivi de bogues, nous n'avons pas besoin de déclencheurs. Cependant, prenons par exemple ce flux de travail du help desk. Dans le cas de l'application help desk, le demandeur sera la personne qui a posé une question. Lorsque cette personne répond par e-mail, nous voudrions que le ticket soit automatiquement déplacé vers l'état Non Résolu car il serait alors porté à l'attention de l'équipe de support. En d'autres termes, nous voudrions que les transitions de la réouverture aient lieu. Dans ce cas, nous définirions nos déclencheurs comme ceci :
L'onglet Gestionnaires d'État
Un gestionnaire d'état est un utilisateur qui est traité comme un gestionnaire lorsqu'une application est dans un état particulier. Ils sont avertis lorsque des choses arrivent à un objet dans cet état. Dans notre exemple ci-dessous, Mark est le responsable de l'AQ, il est donc responsable des états nouveaux et fixes où l'équipe d'AQ est censée travailler.
