Vous avez la possibilité d'autoriser des utilisateurs individuellement ou des groupes entiers à remplacer les règles de routage
normal dans le but de vérifier les incidents au sein de votre entreprise. Par exemple, un utilisateur peut très bien souhaiter
vérifier que les incidents signalés ont été corrigés.
Pour autoriser un tel remplacement, assignez le privilège
Préférences de vérification des incidents à l'utilisateur ou au groupe. Avec ce privilège de sécurité, les utilisateurs peuvent choisir l'une des trois stratégies
suivantes dans :
- Stratégie
- Description
- Toujours utiliser le routage normal
- Routage normal de vérification. L'incident est routé vers la boîte de réception QA appropriée.
- Toujours vérifier votre propre incident
- Demande à Issue Manager de router les incidents soumis par les utilisateurs vers leurs propres boîtes de réception pour vérification, plutôt que
de les router vers la boîte de réception QA habituelle.
- Demander pour chaque nouvel incident
- Demande à Issue Manager de donner aux utilisateurs le choix de remplacer la règle de routage normal à chaque fois qu'un incident est signalé.
La réassignation remplace le routage automatique
La réassignation d'un incident est une méthode de routage manuel qui permet de remplacer le mécanisme de routage automatique.
Un utilisateur peut explicitement appliquer l'action Réassigner pour router un incident vers la boîte de réception d'un autre
utilisateur, généralement du même groupe que le sien. Par exemple, le développeur Bill, qui est parti en vacances, peut réassigner
une anomalie Prêt pour Dév à Dan, son collègue du service Développement. L'anomalie reste à l'état Prêt pour Dév, mais elle
a été réassignée.
Lorsqu'un incident qui a été réassigné revient à un état antérieur dans le workflow, par exemple si Dan décidait de rejeter
un correctif d'anomalie, Issue Manager mémorise la réassignation et renvoie plus tard l'incident dans la boîte de réception vers laquelle l'incident a été routé
manuellement, c'est-à-dire en l'occurrence vers celle de Dan, et non dans celle vers laquelle l'incident a été routé à l'origine,
c'est-à-dire celle de Bill.
Exemple
Pour apprécier à quel point le fonctionnement des réassignations est efficace, examinez l'exemple suivant : une anomalie est
réassignée deux fois (une fois à l'état Prêt pour Dév et une autre fois à l'état Prêt pour QA). L'ingénieur QA rejette un
correctif de cette anomalie et la renvoie de ce fait à un état antérieur dans le workflow.
- Une nouvelle anomalie entre dans le workflow à l'état Prêt pour Dév. Les règles de routage l'envoient automatiquement dans la boîte de réception du développeur Bill.
- Bill réassigne l'anomalie à la boîte de réception du développeur Dan.
- Dan prétend que celle-ci a été corrigée, ce qui a pour effet de la faire passer à l'état Prêt pour QA.
- Les règles de routage envoient automatiquement cette anomalie dans la boîte de réception de Mike, l'ingénieur QA, pour vérification.
- Mike la réassigne à la boîte de réception de sa collègue Sarah.
- Sarah rejette le correctif, ce qui a pour effet de renvoyer l'anomalie à l'état Prêt pour Dév.
- Issue Manager renvoie l'anomalie Prêt pour Dév dans la boîte de réception de Dan, car il est le dernier développeur à être intervenu sur
l'anomalie dans cet état.
- Dan corrige à nouveau l'anomalie, la renvoyant ainsi à l'état Prêt pour QA.
- Issue Manager route à nouveau l'anomalie Prêt pour QA vers la boîte de réception de Sarah, qui est le dernier ingénieur QA à être intervenue
sur l'anomalie à cet état.
Sans la fonction de routage améliorée, l'incident à l'état Prêt pour Dév (étape 7) serait routé vers la boîte de réception
de Bill, qui une nouvelle fois le réassignerait à Dan. De la même façon, l'incident à l'état Prêt pour QA (étape 9) serait
routé vers la boîte de réception de Mike, qui une nouvelle fois le réassignerait à Sarah.