Préférences de remplacement des règles de routage automatique

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 Incidents > Configuration > Préférences :
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.
  1. 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.
  2. Bill réassigne l'anomalie à la boîte de réception du développeur Dan.
  3. 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.
  4. 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.
  5. Mike la réassigne à la boîte de réception de sa collègue Sarah.
  6. Sarah rejette le correctif, ce qui a pour effet de renvoyer l'anomalie à l'état Prêt pour Dév.
  7. 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.
  8. Dan corrige à nouveau l'anomalie, la renvoyant ainsi à l'état Prêt pour QA.
  9. 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.