Règles métier pour les tickets
Les règles métier vous permettent de modifier automatiquement les attributs d'un ticket lorsqu'il est créé ou mis à jour.
Chaque règle possède un ensemble de critères (conditions à satisfaire) et d'actions (modifications à appliquer). Les règles sont évaluées dans l'ordre ; lorsqu'une règle correspond, ses actions sont appliquées et l'évaluation continue avec les règles restantes -- sauf si la règle inclut l'action Arrêter le traitement des règles, qui interrompt immédiatement l'évaluation.
Quand les règles sont déclenchées
Chaque règle est configurée pour se déclencher à la création, à la mise à jour, ou aux deux.
À la création -- tous les critères de la règle sont évalués par rapport aux valeurs soumises.
À la mise à jour -- seules les règles qui ont au moins un critère correspondant à un champ qui a réellement changé sont évaluées. Cela évite des réapplications involontaires lors de la sauvegarde de modifications non liées.
Trois exceptions rendent toujours une règle éligible à la mise à jour, même si le champ n'a pas littéralement changé :
Un utilisateur demandeur a été ajouté ou supprimé -- les règles utilisant
Emplacement du demandeur,Groupe du demandeurouProfilsont réévaluées.Un champ de date de création de calendrier (
_date_creation_calendars_id) est présent -- il n'a pas de valeur stockée à comparer, il est donc toujours considéré comme modifié.Le groupe d'actifs (
_groups_id_of_item) ou l'emplacement du demandeur (_locations_id_of_requester) sont des champs dérivés sans valeur stockée ; même comportement.
Les champs suivants sont toujours disponibles dans les critères lors de la mise à jour (en tant que filtres secondaires) même s'ils n'ont pas été modifiés -- ils sont injectés avec leur valeur stockée actuelle afin que vous puissiez définir la portée des règles par entité, priorité ou statut de validation :
entities_idpriorityglobal_validation(lorsque les approbations sont activées)
Si aucun des critères de la règle ne correspond à un champ modifié, la règle est entièrement ignorée.
Configuration multi-entités
Les règles sont organisées par entité. Dans une configuration multi-entités, lorsqu'un ticket est traité, GLPI évalue d'abord les règles des entités parentes, puis l'entité propre du ticket.
La permission Règles métier (parent) contrôle si un utilisateur peut voir les règles héritées des entités parentes.
Dans la liste des règles d'une entité, trois sections sont affichées :
Règles appliquées (nom de l'entité) -- règles des entités parentes qui s'appliquent ici (visibles uniquement avec la permission Règles métier (parent)).
Règles locales -- règles définies directement sur l'entité actuelle.
Règles applicables dans les sous-entités -- règles de l'entité actuelle qui s'appliqueront également aux entités enfants.
Urgence, impact et priorité
Si une règle définit l'Urgence ou l'Impact, ajoutez une action Recalculer la priorité dans la même règle afin que la Priorité soit mise à jour de manière cohérente. Sans cela, la Priorité conserve sa valeur précédente.
À la mise à jour : seuls les champs modifiés déclenchent les règles
Une règle configurée pour "à la mise à jour" n'est évaluée que lorsqu'au moins un de ses critères correspond à un champ qui a réellement changé lors de la sauvegarde actuelle. Les champs qui n'ont pas changé sont ignorés par le moteur, même si la règle les liste comme critères.
Exception : entities_id, priority et global_validation sont toujours disponibles en tant que critères secondaires pour affiner la portée d'une règle, mais ils ne déclencheront jamais une règle à la mise à jour à eux seuls.
Mis à jour