Configuration des règles de routage

Issue Manager s'appuie sur des règles de routage, sur l'état de chaque incident à l'instant considéré et sur les propriétaires correspondants de cet état pour déterminer les boîtes de réception vers lesquelles les incidents doivent être routés au cours de leur cycle de vie. Ce mécanisme de routage sophistiqué remplace ce qui serait autrement une tâche fastidieuse pour des personnes chargées de répartir les incidents.

L'état d'un incident reflète sa situation à un instant donné. Un certain nombre d'états sont fournis dans le workflow par défaut d'Issue Manager. Le propriétaire de l'état est le rôle, dans votre organisation, qui a la responsabilité d'agir sur un incident se trouvant dans un certain état.

Voici des exemples d'états d'incidents et de leurs propriétaires dans le workflow par défaut :
Non Vérifié
Quelqu'un doit déterminer si cet incident est vraiment une anomalie ou une erreur de documentation. Habituellement, ce rôle est tenu par un ingénieur QA.
Prêt pour Dév
Le code est prêt à être pris en compte. Ce rôle est généralement détenu par un développeur.
Prêt pour QA
Quelqu'un doit vérifier que le bug a effectivement été corrigé. Ce rôle est habituellement détenu par un ingénieur QA.

Différents incidents de même type peuvent entrer dans le workflow dans différents états, en fonction de qui les soumet. Le routage est affecté en conséquence. Par exemple, un incident soumis par un développeur entre dans le workflow dans l'état Prêt pour Dév, il est donc routé vers la boîte de réception d'un développeur. Un incident soumis par un utilisateur de l'entreprise entre dans le workflow dans l'état Non Vérifié, il est donc routé vers la boîte de réception d'un ingénieur QA. L'état initial d'incident, ainsi nommé, est défini dans les paramètres de groupe.

Un incident passe d'un état à un autre dans le workflow quand un utilisateur agit sur cet incident. Par exemple, lorsqu'un ingénieur QA confirme qu'un incident signalé non vérifié est bien une anomalie, ce dernier passe de l'état Non Vérifié à l'état Prêt pour Dév. Ici, l'objectif principal de l'emploi de la logique de routage est de garantir qu'une fois que l'incident est considéré comme une anomalie par l'ingénieur QA, il passe de sa boîte de réception à celle du développeur concerné sans qu'il soit nécessaire d'intervenir manuellement.