GlpiCalendar

Utilisation des calendriers :

  • Peuvent être rattachés aux SLA
  • Servir pour définir les horaires d'exploitation / ouverture pour le helpdesk.

Utilisation pour les SLAs (cf. GlpiSla)

  • Un calendrier est facultatif pour une SLA. Si pas de calendrier on prend les jours calendaires.
  • Le calendrier est constitué :
    • Jours fériés : Détermination des jours fériés : Date et description
    • Heures d'exploitation :
      • Détermination des heures effectives par jour ou d'un système 24/24
      • Détermination des jours de fonctionnement du helpdesk sur la semaine

Mise en oeuvre

Comment coder / stocker le calendrier ?

  • Horaires à la minute

Multi horaires dans la journée : 8-12 + 14-18 ? ou une plage par jour ? une plage tous les jours ?

  • yllen : une plage tous les jours n'est pas suffisant.
    Pour les entreprises accueillant du public, les horaires sont souvent du lundi après-midi au samedi matin.
    De même, en France, avec les RTT, chaque entreprise a revu ses horaires, souvent en réduisant les horaires du dernier jour travaillé.
    Par contre, on peut avoir besoin de 2 plages différentes par jour suivant le demandeur car une même entité peut avoir plusieurs services helpdesk.
    Par exemple, chez nous, un centre informatique régional n'a pas les mêmes exigences pour les incidents concernant ces propres agents (quelques personnes concernées) que pour les incidents des CPAM dépendant de lui (un serveur en panne en central ce sont des milliers de personnes bloquées).
  • MoYo : donc ca dépend bien de l'entité de l'utilisateur et donc de l'entité de rattachement du ticket ?

Un jour = une plage ou sinon obligation de gérer des plages d'ouverture et non des jours. Une plage : jour + début + fin

  • yllen : si on parle de plages d'ouverture, on va avoir la demande d'avoir une plage attachée à un lieu et plus à une entité, surtout dans les grosses entreprises avec de multiple succursales. En effet, souvent le service helpdesk suit les horaires d'ouverture au public.
  • MoYo : c'est bien toute la question : a quoi sert le calendrier autrement que pour les SLAs ? Je n'ai pas de réponse plus précise à cette question ?

Remi : Oui : entité du ticket (pour ITIL c'est le client qui compte)

  • JMD remarque avant la conclusion : je crois qu'on s'égare là. Soit le ticket match une SLA et on peut traiter tous les cas soumis par Yllen (à l'aide des business rules). Soit le calendrier ne match pas une SLA et c'est le calendrier par défaut de l'entité qui traite le ticket qui s'applique.

Remi : Oui : donc prévoir un champ "is_default" pour le calendrier.

MoYo : Si pas de calendrier pour l'entité on peut aussi prendre celui de l'entité mère et à défaut les jours calendaires.

Conclusion temporaire sur le choix multi-plage ou plage unique : Ensemble de plages plus souple et pas forcement plus complexe à gérer.

Oui, c'est forcément mieux

  • Jour fériés : Définition générale avec ajout de dates pour les jours fériés flottants (1 jour fériés = plusieurs dates / une par année)
    • Jour fériés plutôt Périodes de fermetures : liste de jours : permet de gérer les vacances / jours fériés...
    • Les jours peuvent être récurrent : Noël par exemple. Pouvoir définir un jour comme récurrent (non lié à une année)
      • yllen : je pensais également à mettre un champ is_perpetual pour lister les jours fériés fixes (noël, 14 juillet, D.Day...)
      • remi : oui
  • Le calcul d'une date d'échéance doit être le plus simple possible (mais forcément complexe).
    • Quelles valeurs précalculées peut-on stocker ? durée ouverture d'un jour / d'une semaine ?

Remi : oui il faudra un mécanisme de cache pour les délais, sinon ce sera ingérable au niveau perf.

Horaires d'exploitation pour Helpdesk

  • Buts ?
    • Avoir des stats plus fines
      • MoYo : il me semble compliqué de refaire les calculs à chaque fois avec un calendrier. Quelles informations doit t'on stocker ?
      • Les éléments actuellement calculés : Durée de traitement (fermeture - ouverture) / Durée réelle d'intervention / Durée de prise en compte (première action - ouverture)
  • Utilisation / Gestion
    • Rattachement d'un calendrier à une entité. Si pas de calendrier défini on prend celui de l'entité mère. Si pas de calendrier du tout, on prend les jours calendaires (comme actuellement)
  • Un ticket est associé à une entité. On utilise donc le calendrier courant de l'entité pour faire les calculs pour les stats (rem. la SLA potentiellement associée peut utiliser un autre calendrier)
  • Mise en oeuvre :
    • Exactement les même questions que pour les SLAs

Considérations générales :

  • Qui peut créer / modifier des calendriers ?
    • l'administrateur global uniquement ou définition possible par entité ?
      • yllen : pour moi définition par entité ne serait-ce que pour les entités mères avec sous-entités internationales. Je verrais bien le superviseur de la plate-forme de helpdesk.
      • MoYo : donc un droit de plus pour éditer les calendriers a priori
      • Remi : le droit "entity_dropdown" pourrait suffire, un nouveau droit c'est forcément mieux.
  • Qui peut modifier une entité pour lui associer un calendrier ?
    • Celui qui a le droit de modifier une entité : donc l'admin global ?
      • Yllen : pour moi oui
      • Remi : on parle de transfert de calendrier existant ? donc oui, l'admin global.
        • MoYo : non pas de transfert mais qui a le droit d'associer un calendrier à une entité ? Si on considère que c'est une propriété de l'entité, seul ceux qui ont le droit de modifier les entités pourront modifier le calendrier affecté à l'entité.
  • Ne peut-on pas gérer le calendrier d'exploitation comme une SLA par défaut ?
    • risque de perturber les utilisateurs qui ne veulent pas utiliser les SLA.
  • Si on a une SLA sur le ticket on utilise le calendrier (ou la non existence de calendrier) de la SLA pour faire les calcul de stats.
  • Problème de sortie de la SLA (quand redéfinition de la date d'échéance) - recalcul nécessaire des stats car possible changement de calendrier. Il faut donc stocker les dates de changements (prise en compte...) pour pouvoir faire le recalcul.
  • Possibilité de cloner un calendrier pour faciliter la création.