Flux d'approbation multiniveau pour les tickets GLPI

Configurez des flux d'approbation multiniveaux par catégorie de ticket dans GLPI - les chaînes séquentielles que la validation native en une seule ronde ne sait pas exprimer, sans code sur mesure.

Dans GLPI, l'"approbation" native tient en une seule ronde. Vous demandez la validation d'une ou plusieurs personnes, définissez un pourcentage d'acceptation, et c'est tout - il n'existe pas d'enchaînement hiérarchique où la finance n'est sollicitée qu'après l'approbation du responsable direct. Le module Approval Flow de NexTool comble précisément ce manque.

Le problème : l'approbation hiérarchique n'existe pas dans le core

En entreprise, approuver un ticket couvre souvent plus d'un niveau : le responsable direct valide, puis la finance vérifie le budget, puis la direction signe. C'est un flux séquentiel - chaque étape n'a de sens qu'après l'approbation de la précédente. GLPI ne modélise pas cela.

Ce que le core propose, c'est une ronde de validation unique. Vous ouvrez l'onglet des approbations, choisissez des validateurs (utilisateurs ou groupes) et définissez le champ validation_percent - la part d'approbations nécessaire pour que le ticket soit considéré comme validé. Tous les validateurs reçoivent la demande en même temps. Pas d'ordre, pas de "le niveau 2 ne se déclenche que si le niveau 1 approuve", pas de chemin distinct en cas de refus.

Pourquoi émuler des niveaux avec validation_percent ne marche pas

Dans notre activité de support et de maintenance, le montage que l'on voit le plus souvent est la tentative de forcer une séquence avec le champ de pourcentage : l'équipe demande la validation de trois personnes et met 100%, en s'attendant à une chaîne. Ce n'en est pas une. Les trois reçoivent la demande simultanément - la direction la voit avant même que le responsable direct l'ait regardée. Pire : si l'un refuse, le ticket passe à REFUSED, mais les demandes des autres restent en attente dans leur file "mes validations", encombrant la vue de chaque approbateur. Et impossible de dire "en cas de refus, escalade vers un autre niveau" ou "en cas d'approbation, ferme automatiquement avec ce modèle de solution". Le plus souvent, l'équipe abandonne la fonction native et gère la chaîne par e-mail, hors du système - ce qui tue la traçabilité et ouvre une faille d'audit.

Comment fonctionne Approval Flow

Le module Approval Flow ajoute des flux d'approbation multiniveaux liés aux catégories ITIL des tickets, en réutilisant les modèles de validation natifs de GLPI (ITILValidationTemplate) - ainsi, celui qui approuve continue d'utiliser l'onglet d'approbations standard, sans écran parallèle.

  • Un flux par catégorie ITIL - chaque catégorie a au plus un flux actif, ce qui supprime l'ambiguïté sur la règle qui s'applique à ce ticket.
  • Niveaux enchaînés en arbre - chaque niveau a des chemins indépendants pour l'approbation et le refus, vous définissez donc des issues différentes par branche.
  • Action configurable par issue - à l'approbation ou au refus, vous choisissez ce qui se passe : ne rien faire, résoudre, clôturer ou passer au niveau suivant.
  • Solution normalisée - quand l'action est résoudre ou clôturer, lier un SolutionTemplate est obligatoire, ce qui garantit le même message au demandeur sur tous les tickets.
  • Déclenchement automatique - à la création d'un ticket dans une catégorie avec un flux actif, la validation du premier niveau est demandée d'elle-même, sans que personne ait à penser à ouvrir l'onglet d'approbations.
  • Utilisateurs ou groupes par niveau - chaque niveau peut pointer vers une personne précise ou un groupe, avec les mêmes cibles que le validateur natif.
AspectValidation native GLPIApproval Flow
RondesUne seule ronde plateNiveaux enchaînés en arbre
SéquenceTout le monde la reçoit en même tempsLe niveau suivant ne se déclenche qu'après approbation du précédent
Refusglobal_validation = REFUSED, sans action ultérieureChemin de refus propre (résoudre, clôturer ou escalader)
DéclenchementManuel, via l'onglet d'approbationsAutomatique par catégorie ITIL à l'ouverture du ticket
ApprobateursUtilisateurs ou groupes, tous pairsUtilisateur ou groupe défini par niveau
Action après la décisionAucune automatiqueRésoudre/clôturer via SolutionTemplate ou avancer

Diagnostic : où lire l'état de l'approbation

Avant de concevoir un flux, il est utile de savoir où GLPI conserve l'état natif - c'est ce que le module orchestre en dessous. Deux requêtes couvrent la lecture :

-- GLPI : inspecter l'état de validation natif d'un ticket.
-- global_validation et status suivent CommonITILValidation :
--   1 = NONE     (non soumis à approbation)
--   2 = WAITING  (en attente)
--   3 = ACCEPTED (approuvé)
--   4 = REFUSED  (refusé)

SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;

-- Demandes individuelles : nativement, ce sont toutes des "pairs" dans la MÊME ronde.
-- Il n'existe ni colonne de "niveau" ni ordre hiérarchique.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;

Si vous tentez déjà de simuler des niveaux avec plusieurs validateurs, la deuxième requête rend le problème évident : plusieurs lignes en status = 2 (WAITING) en même temps, sans aucune colonne exprimant l'ordre. C'est le manque que comble le flux enchaîné.

Comment l'activer

  1. Installez NexTool sur votre GLPI (10.0+ ou 11.0+).
  2. Allez dans Configuration > NexTool > Modules.
  3. Activez Approval Flow et cliquez sur Configurer.
  4. Dans l'onglet Flux, créez un flux et liez-le à la catégorie ITIL voulue.
  5. Définissez les niveaux, les approbateurs (utilisateur ou groupe) et l'action de chaque issue (approuver/refuser).
  6. Pour les actions résoudre ou clôturer, liez le SolutionTemplate correspondant.

Pour qui (et quand ne pas l'utiliser)

Il convient aux organisations qui ont besoin d'une gouvernance IT formelle : demandes d'accès, achats, changements d'infrastructure, tout ticket exigeant une signature hiérarchique avec traçabilité au sein même de GLPI. Aussi aux équipes qui pratiquent ITIL et ne veulent pas que leur chaîne d'approbation vive dans une boîte mail.

Cela ne vaut pas la peine si votre approbation tient sur un seul niveau - dans ce cas la validation native de GLPI suffit déjà, et ajouter un flux enchaîné ne fait qu'empiler de la configuration sans gain. Cela ne remplace pas non plus un moteur BPM complet : le périmètre est l'approbation de tickets, pas l'orchestration de processus arbitraires avec formulaires et intégrations externes.

Compatibilité

  • GLPI : 10.0+ et 11.0+
  • Offre : PAID
  • Plugin : NexTool 3.x+

Étape suivante

Approval Flow fait partie de NexTool, un écosystème de modules qui étend GLPI sans toucher au code du core. Parlez à l'équipe pour voir le flux multiniveau fonctionner sur votre scénario.


Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe NexTool Solutions.

Questions fréquentes

Non. La validation native de GLPI est une ronde unique : vous demandez l'approbation d'un ou plusieurs validateurs et définissez le champ validation_percent (part d'acceptation). Tout le monde reçoit la demande en même temps, sans ordre hiérarchique. Approval Flow ajoute les niveaux enchaînés, où le niveau suivant ne se déclenche qu'après l'approbation du précédent.

validation_percent est un seuil sur des validateurs qui reçoivent la demande simultanément - par exemple, 100% exige que tous approuvent, mais tous approuvent en parallèle. Un flux enchaîné est séquentiel : il conditionne le déclenchement du niveau N+1 à l'approbation du niveau N et autorise des chemins distincts pour l'approbation et le refus.

Non. Le module réutilise la validation native (ITILValidationTemplate) et l'onglet d'approbations standard du ticket. Celui qui approuve continue d'utiliser l'interface qu'il connaît déjà ; le module ne fait qu'orchestrer la séquence des niveaux et l'action de chaque issue.

C'est vous qui décidez. Chaque issue (approuver ou refuser) a une action configurable : ne rien faire, résoudre, clôturer ou passer au niveau suivant. Pour résoudre ou clôturer, lier un SolutionTemplate est obligatoire, ce qui garantit le même message au demandeur.

Oui. Chaque catégorie ITIL peut avoir au plus un flux actif, avec ses propres niveaux et approbateurs (utilisateurs ou groupes). Ainsi, les tickets d'accès suivent une chaîne et les tickets d'achat une autre, sans ambiguïté sur la règle qui s'applique.

Besoin d'aide ?