Règles métiers à la mise à jour d'un ticket

Besoin fonctionnel

Qu'à la mise à jour d'un ticket, le moteur des régles métiers pour les tickets soient jouées.
Actuellement, le moteur de règles métiers pour les tickets n'est joués qu'à la création du ticket.

Exemples :
  • Une règle métier indiquant : si priorité = majeure alors affecté au technicien Sauveur
    La demande est basculée en incident majeure manuellement, on souhaite quand même que la règle d'association au technicien Sauveur
  • Une règle métier indiquant : si catégorie = XXXX et priorité = ZZZ alors affecté à la SLA YYYY
    Le ticket change de catégorie, il faudrait qu'il change également de SLA

Analyse fonctionnelle

Principe général

2 options : Nouveau moteur de règle ou évolution vers un moteur de règle avec paramétrable (2eme solution expliquée)
2eme option peut permettre à terme d'envisager des évolutions sur les autres moteurs pour par exemple définir des règles de dictionnaires applicables uniquement à la création et/ou du "rejouage" du dico

Faire évoluer le moteur de règle pour ajouter un élément de critère dans les règles permettant de dire si la règle sera jouée :
  • à la création
  • à la mise à jour
  • à la création et à la mise à jour
    Ce champ qui pourra être générique pourrait être utilisé dans d'autres moteur pour conditionner d'autres moteurs de règles.
    Le moteur de règle utilisera ce critère pour filtrer les règles à utiliser dans tel ou tel cas (création ou mise à jour).

Fonctionnement détaillé :

Actuellement, le moteur de règle utilise en entrée 2 paramètres $input et $output :
  • $input contient les paramètres qui seront utilisés les critères.
  • $output les résultats des actions jouées.
  • pour les tickets $input = $output = données du ticket

Hors, pour le moteur à la mise à jour des tickets, il ne faut prendre en compte que les champs qui ont été modifiés.
Il faut donc pouvoir ne jouer que les règles qui ont au moins un de ces champs en critère (cf. exemple 2).
Toute autre modification manuelle ne doit pas redéclencher une modification (dans l'exemple 1, on ne va pas tenter d'ajouter le technicien à chaque fois)
Il faut donc faire évoluer le moteur de règle pour pouvoir également ne jouer que les règles nécessaire.
Il faut donc un paramètre en plus que $input et $output pour indiquer les éléments de critères à prendre en compte.
On peux imaginer que les critères évoluent au fur et à mesure des règles jouées (on ajoute les champs modifiés par les règles au fur et à mesure)
afin de permettre un enchainement des règles (une règle qui définit la priorité et la suivante qui a la priorité en critère).

Mise en place technique

Techniquement la mise en oeuvre n'est pas simple.
Concernant le critère supplémentaire dans les règles :
  • Ajout d'un champ condition dans glpi_rules (entier).
  • Pour les moteurs l'utilisant, définition des conditions possibles getConditions.
    • Si vide on ne proposera pas le critère
    • Si définit on proposera un dropdown de sélection. Une fonction devra permettre de construire la condition SQL permettant à partir de cette sélection de filtrer les règles en entrée (getConditionRestrictQuery).
  • Ajout d'un paramètre à RuleCollection::getCollectionDatas pour passer la condition, calcul de getConditionRestrictQuery dans cette fonction pour passer ma condition à getRuleListQuery.
    • On ajouterait alors le paramètre aux différents processAllRules.
    • Pour les tests des moteurs il faudra aussi ajouter le choix de la condition en amont pour savoir quels critères doivent être demandés
Concernant le filtrage des règles en fonction des critères à utiliser :
  • Ce filtrage ne peut se faire en amont si on fait évoluer les critères à prendre en compte au fur et à mesure du passage des règles pour gérer les enchainements
  • Ajouter un élément en plus dans $params de processAllRules (only_criteria) dans lequel on indique les critères à prendre en compte.
  • Le moteur mettra à jour only_criteria à chaque passage de règle en fonction des actions réalisées (directement dans executeActions ? pb avec plugins)
ANNEXES :
  • simplifier executeActions classes (n redéfinitions des cas simples append / assign) : cas par défaut : call parent::executeActions