Pour définir vos propres règles, vous devez :
Vous trouverez ci-dessous des conseils importants qui vous aideront à écrire syntaxiquement et sémantiquement des clauses WHERE valides.
Vos clauses SQL WHERE nécessiteront probablement des références à IM_V_Defects et IM_DefectHistory. La vue IM_V_Defects stocke des informations qui sont actuelles pour un incident alors que la table IM_DefectHistory conserve un enregistrement de toutes les actions qui ont été effectuées sur un incident, ainsi que les impacts de ces modifications sur certains champs d'incidents.
Par exemple, IM_DefectHistory stocke une assignation de boîte de réception d'un incident avant qu'une action soit effectuée, ainsi que l'assignation de la boîte de réception après l'action. Ces colonnes sont AssignedIN pour l'assignation de boîte de réception avant l'action et AssignedOUT pour la nouvelle boîte de réception.
Toutes les actions effectuées sur des incidents sont enregistrées dans le champ ActionCode de la table IM_DefectHistory. Ces actions apparaissent sous la forme de codes action dans la colonne Action de l'onglet Historique. Vous avez peut-être remarqué des codes tels que CORRIGE et VERIFIE dans l'exemple de base de données.
Pour visualiser les codes action pour la plupart des actions de votre base de données, consultez la boîte de dialogue Modifier l'Action de l'Etat de chaque état (les exceptions sont SAISI, REASSIGNE et MODIFIE, qui sont figées dans le code et ne peuvent pas être consultées). Pour accéder à la boîte de dialogue Modifier l’Action de l’Etat, accédez à et cliquez sur le nom d'un état dans la colonne Libellé du Bouton. Consultez la valeur du champ Code Action de l'Historique.
Les champs personnalisés sont identifiés dans la vue IM_V_Defects en tant que Custom1 , Custom2 etc., en fonction de leur position dans les onglets. Chaque onglet personnalisé comporte un maximum de 10 champs, 1 à 10, 11 à 20, etc. Dans l'Onglet Personnalisé 1, les cinq premiers champs apparaissent en ordre décroissant dans la colonne de gauche ; les champs 6 à 10 apparaissent en ordre décroissant dans la colonne de droite.
Pour trouver le nom de schéma d’un champ personnalisé spécifique, accédez à . Par exemple, dans la boîte de dialogue de l'exemple de base de données, la case Ajouter une Note de Release? est le quatrième champ de la colonne de gauche de l'Onglet Personnalisé 1, tout comme Custom4 dans la table des incidents.
La valeur d'une case non cochée est '.' (un point). La valeur d'une case cochée est 'X' (X en majuscule).
Par exemple, pour récupérer tous les incidents pour lesquels la case Ajouter une Note de Release? est cochée, vous indiquez l'élément suivant dans la clause WHERE :
D.Custom4 = 'X'
Vous trouverez ci-dessous quatre situations dans lesquelles vous souhaiterez peut-être créer une nouvelle règle. Les deux premières situations suggèrent des règles utilisées dans les notifications d'incidents spécifiques. Les deux dernières situations suggèrent des règles utilisées dans des notifications à l'échelle du projet. A la suite de chaque exemple, vous trouverez la clause WHERE écrite pour l'exemple de base de données.
Le support technique ainsi que d'autres groupes souhaitent savoir lorsque la correction d'une anomalie spécifique a été vérifiée comme étant corrigée.
La clause WHERE se présente ainsi :
DH.ActionCode = 'VERIFIED'
La valeur de ActionCode dans la table IM_DefectHistory est mise à jour chaque fois qu'un utilisateur effectue une action ; en conséquence, le support technique ne recevra le courriel qu'une seule fois, lorsque l'action Vérifier provoque la saisie du code action VERIFIE dans la table IM_DefectHistory et dans l'onglet Historique.
Si la clause était écrite à la place en référence au Code cause (nommé Disposition dans la base de données) :
D.Disposition = 'FIXED'
alors le support technique recevrait certainement le courriel plusieurs fois car le code cause resterait CORRIGE dans la base de données. Un utilisateur qui ajouterait ultérieurement un commentaire ou enregistrerait l'incident déclencherait un courriel car la règle correspondrait toujours.
Un utilisateur quelconque, qui n'agit pas sur les anomalies, souhaite savoir ce qui est arrivé à l'anomalie qu'il a saisie. Notamment, il souhaite recevoir un courriel lorsque l'anomalie a attiré l'attention d'un développeur. En termes de workflow, cela signifie que l'incident vient juste de quitter l'état Prêt pour Dév (Dev-Ready) et, en conséquence, la clause WHERE doit tester la modification de l'état après l'action.
La clause WHERE se présente ainsi :
DH.StatusIN = 'Dev-Ready' AND DH.StatusOUT <> 'Dev-Ready'
L'état était Prêt pour Dév (Dev-Ready) avant l'action mais après l'action du développeur, l'anomalie a pris un autre état.
Le département de documentation envoie tous les problèmes documentation à une boîte de réception de groupe, Doc (Product A), au lieu d'utiliser la boîte de réception d'un utilisateur, Judy -- Doc, par exemple. Le gestionnaire de la documentation souhaite recevoir un courriel lorsqu'un incident entre dans la boîte de réception.
La clause WHERE se présente ainsi :
DH.AssignedIN <> 'Doc (Product A)' AND DH.AssignedOUT = 'Doc (Product A)'
Elle indique qu'un courriel doit être envoyé lorsque la boîte de réception avant l'action n'était pas Doc (Product A) mais après l'action est Doc (Product A). Le courriel ne sera envoyé qu'une seule fois, lorsque le problème documentation est routé vers Doc (Product A).
Notez que sans la première partie de la clause WHERE, le gestionnaire de documentation recevrait un courriel lorsque n'importe quelle action aurait été effectuée sur le problème documentation lorsqu'il était assigné à Doc (Product A). Bien que la règle soit susceptible de générer un grand nombre d'e-mails, puisque la notification doit être appliquée à l'échelle du projet, les deux lignes de la clause WHERE limitent la règle à un seul événement : lorsque la boîte de réception devient Doc (Product A).
Il n'est pas nécessaire que la règle indique que le type d'incident soit PB DOCUMENTATION, bien que cela ne soit pas incorrect puisque Doc (Product A) ne contient que des incidents relatifs à la documentation.
Le gestionnaire de release souhaite recevoir un courriel au cours du mois suivant avant une release majeure relative aux anomalies les plus graves qui ne peuvent pas être corrigées. La clause WHERE doit tester la sévérité, Product B et le code action Pas Corrigeable (Cannot-Fix) assignés lorsqu'un développeur effectue l'action Pas Corrigeable.
La clause WHERE se présente ainsi :
D.Severity = '1: Fatal/Data Loss' AND DH.ActionCode = 'Cannot-Fix' AND D.ProductCode = 'Product B'
Ces restrictions sont nécessaires car si la clause WHERE teste seulement la sévérité alors la règle correspondra chaque fois que l'incident est modifié et enregistré car la sévérité ne changera pas tant qu'un utilisateur ne la modifie pas explicitement.
Le gestionnaire de release recevra peut-être un grand nombre d'e-mails, notamment si cette règle est appliquée par une notification à l'échelle du projet. Néanmoins, il peut facilement supprimer la notification une fois que le cycle de release est terminé.
Travaillez du général vers le spécifique. Tout d'abord, prenez en considération les situations d'entreprise générales qui peuvent requérir des règles de notification par courriel. Vous pouvez demander à tous les utilisateurs Issue Manager quand ils souhaitent recevoir un courriel relatif à des incidents. Définissez précisément les informations que chaque utilisateur souhaite retirer du courriel. Par exemple, un utilisateur peut vous indiquer qu'il souhaite savoir quand une anomalie est corrigée. Après une discussion approfondie, vous découvrirez peut-être que ce qu'il souhaite vraiment savoir est quand l'anomalie est vérifiée par un ingénieur QA. Cette différence subtile peut nécessiter une clause WHERE différente.
Ensuite, lorsque vous êtres satisfait de votre compréhension des besoins des utilisateurs, traduisez la situation en termes de workflow de votre organisation.
Enfin, rédigez la clause SQL WHERE. Tentez de tester la clause WHERE par l'intermédiaire d'une requête avancée afin de vous assurer que vous indiquez les conditions exactement comme prévu.
D'une manière générale, les règles relatives aux notifications sur des incidents spécifiques doivent être écrites de manière simple et générique alors que les règles relatives aux notifications à l'échelle du projet doivent être aussi précises et restrictives que possible afin d'éviter l'envoi d'un nombre excessif d'e-mails.
Demandez-vous si les utilisateurs souhaitent recevoir des notifications une seule fois ou chaque fois qu'une modification est apportée. Si un utilisateur ne veut recevoir un courriel qu’une seule fois, rendez les règles plus restrictives.