Spécification de la gestion des OLA dans GLPI

Contexte actuel

https://support.teclib.com/front/ticket.form.php?id=36566

https://support.teclib.com/front/ticket.form.php?id=36563

Actuellement, dans GLPI, la gestion des SLA et OLA est intégrée directement dans l’entête des tickets, avec des champs dédiés comme TTO, TTR, TTO interne, TTR interne, etc. Ces champs sont utilisés pour calculer les délais de traitement et d'attente, mais cette gestion ne permet pas de suivre les OLA de manière précise, surtout lorsque plusieurs groupes ou techniciens sont impliqués dans la prise en charge du ticket.

Objectifs

• Séparer les informations de SLA et OLA.

• Permettre une gestion des OLA pour chaque groupe (plutôt que pour le ticket dans son ensemble).

• Gérer la période d'attente pour ajuster les délais d’échéance.

• Suivre plus finement les interventions, les groupes et les techniciens impliqués dans le traitement des tickets.

Proposition de solution

Créer une table dédiée à la gestion des OLAs associée aux tickets. Cette table permettra de suivre l’évolution distinctes des OLA et leurs changements, tout en prenant en compte les périodes d'attente.

Changements DB

Ajout d’un champ groups_id à la table glpi_olas

Pour suivre les actions des utilisateurs relatifs à ce groupe. Une liste déroulante correspondante sera affichée dans le formulaire d’un OLA.

Les groupes listés ici doivent posséder la colonne “Assigned to” sur Oui.

On indiquera rapidement dans un “helper” en quoi consiste le suivi du groupe.

Nouvelle table glpi_items_olas

La table glpi_items_olas sera utilisée pour stocker les informations spécifiques liées aux OLA pour chaque ticket.

Plusieurs OLA pourront être définis par ticket, avec leurs informations spécifiques sur les délais, les statuts et les périodes d'attente.

CREATE TABLE `glpi_items_olas` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `itemtype` varchar(255) NOT NULL,          -- Type de l'élément (par exemple : 'Ticket')
  `items_id` int unsigned NOT NULL,          -- ID de l'élément (ID du ticket)
  `olas_id` int unsigned NOT NULL,           -- ID de l'OLA (référence à la table des OLA)
  `start_time` timestamp NULL DEFAULT NULL,  -- Heure de début (affectation de l'OLA au ticket)
  `due_time` timestamp NULL DEFAULT NULL,    -- Heure d'échéance (prise en compte de l'attente)
  `end_time` timestamp NULL DEFAULT NULL,    -- Heure de fin de prise en charge
  `status` int NOT NULL,                     -- Statut de l'OLA : 0 = En cours, 1 = Respecté, 2 = Dépassé
  `waiting_time` int NOT NULL DEFAULT 0,     -- Durée d'attente (en secondes, période en statut "En attente")
  PRIMARY KEY (`id`)
);

Les champs suivants seront utilisés pour suivre la gestion des OLA :

• start_time :

  • Définie comme la date d'affectation de l’OLA au ticket, via les règles ou manuellement.

• due_time :

  • Calculée à partir de start_time et du délai OLA correspondant (ex. 4 heures pour le TTO).

  • Si le ticket passe par un statut en attente pendant un certain temps, cette période est ajoutée à la durée totale pour ajuster le due_time.

• end_time :

  • Date de fin de prise en charge du ticket par un technicien du groupe ou quand le groupe est retiré.

  • Cela correspond à l'instant où un technicien du groupe finit à travailler sur le ticket

  • Ça ne prend pas en compte l’intervention d'un technicien extérieur au groupe affecté.

• waiting_time :

  • Durée pendant laquelle le ticket est en statut "En attente".

  • Calculée comme la durée entre la dernière activité effectuée sur le ticket et le moment où le ticket passe en statut "En attente".

  • Cette valeur est utilisée pour ajuster la due_time afin de tenir compte du temps d'attente avant qu’une action ne soit réalisée sur le ticket.

    
    

Impact sur la table glpi_tickets

Voici la liste des colonnes à supprimer de glpi_tickets :

• olas_id_tto

• olas_id_ttr

• olalevels_id_ttr

• ola_tto_begin_date

• ola_ttr_begin_date

• ola_waiting_duration

• internal_time_to_resolve

• internal_time_to_own

Ces colonnes sont directement liées à la gestion des OLA et ne seront plus nécessaires dans glpi_tickets.

Les données existantes seront migrées dans la table glpi_items_olas décrite précedemment.

Précision sur les déclencheurs

Affection d’un OLA

Comme précédemment par les règles métiers pour les tickets (On affecte d’ailleurs toujours des objets OLA directs et non des SLM, ceci impliquant d’affecter via une règle un TTO ou un TTR unitairement. Note une règle peux affecter plusieurs OLA) ou par une action manuelle dans l’interface d’un ticket

Prise en charge

• Un membre du groupe défini pour l’OLA effectue une action sur le ticket, pour les TTO.

• nouvelle action dans les règles métier pour les tickets

Résolution

• Le ticket est résolu.

• Le groupe suivi est supprimé du ticket.

• Nouvelle action dans les règles métier pour les tickets.

Mise en pause

• Status ticket devient en attente.

• Nouvelle action dans les règles métier pour les tickets.

Reprise (suite mise en pause)

• Status ticket sort de l’attente.

• Nouvelle action dans les règles métier pour les tickets.

Affichage

• on affiche les informations relatives au SLA sur 1 seul ligne pour gagner de la place

• on supprimer les helpers qui servaient a afficher les labels complets. Il seront remplacés par des tooltips sur les acronymes. Cela permettra un gain de place en largeur

• on ajoutera des icônes de drapeaux pour symboliser les objectifs de temps

• On prendra le style par défaut des champs horizontaux (texte du label aligné à droite)

• les informations de LevelAgreement et EscalationLevel resteront identiques. Juste quelques corrections pour s’assurer de l’alignement vertical

• Pour les OLA, on affichera en plus le group associé si il existe

• On groupera ces OLA par groupe, puis TTO > TTR

• On préféra ne pas “wrap” sur le badge du level mais avant celui ci dans le cas de très long textes

  
  

Propositions

CF proposed html for service level accordion, une proposition d’html.

ligne de SLT:

Interface de base

Interface avec passage à la ligne des contenu trop longs.

Status des dates cibles

TTR/TTO dépassé

TTR/TTO réussi

En cours

Divers

• L’onglet destination des formulaires permet de définir des OLA, il faudra vérifier comment intégrer ça.

  
  

Conclusion

Cette nouvelle gestion permet de suivre précisément chaque OLA associée à un ticket, tout en tenant compte des différents groupes impliqués, des périodes d'attente et des actions réalisées. La séparation de la gestion des OLA de la table glpi_tickets permet une plus grande flexibilité et une gestion plus fine des délais et des affectations.