Multi Demandeur sur un ticket

  • Objectif : permettre de définir plusieurs demandeurs sur un ticket (groupe ou user)
  • Actuellement les demandeurs sont définis par :
    • un groupe groups_id
    • un utilisateur users_id
    • pour le suivi par email un champ user_email et un boolean use_email_notification pour savoir si on notifie l'utilisateur
  • Au niveau des groupes demandeurs la gestion de plusieurs groupes peut être réalisé simplement via une table de liaison.
  • Au niveau des utilisateurs une table de liaison est nécessaire mais pose le problème de la gestion du mail libre et du choix de notification :
    • Chaque utilisateur pourra choisir ou non de recevoir les notifications
    • pour chaque utilisateur on peut permettre à celui-ci de définir un email alternatif si son email normal n'est pas correct
      • actuellement on duplique le mail de l'utilisateur à chaque fois ce qui ne semble pas forcément intéressant (faire le ménage ?)
      • Idée : ne proposer le choix d'un email manuel que si l'utilisateur n'a pas d'email ou si il en fait le choix explicite (case à cocher par exemple)
        Walid : bonne idée. Effectivement dans beaucoup de cas, ça ne sert à rien de montrer l'email, puisque l'utilisateur a son email rempli correctement dans GLPI
Walid :
  • est ce qu'il peut y avoir plusieurs demandeurs si le ticket provient d'un email ? si oui, est ce qu'on prend les personnes en CC ?
    • MoYo : pour moi les cc doivent être considérés initialement comme des observateur non comme des demandeurs. Sans ce nouveau typage je ne les prendrais pas en compte.
  • dans le cas de l'approbation pour clotûre, il suffit qu'un seul demandeur donne son accord ou il faut que tous le donne ?
    • MoYo : pour moi un seul. une fois que c'est validé basta.

Pratiquement :

  • table glpi_groups_tickets : id, tickets_id, groups_id
  • table glpi_tickets_users : id, tickets_id, users_id, use_notification, alternative_mail
  • Voir un peu plus loin :
    • Pour gérer les multi-techniciens (user ou groupes), au choix :
      • Dupliquer ses tables pour les techs (avec ou sans les champs de notif)
      • Ajouter un typage sur les liaisons (type = requester / assign) pouvant être étendu (lastupdater, receiver).
        • Ca pourrait permettre de définir des choses du genre : observer également (utilisateur pouvant observer mais sans aucune action possible).
          • Le demandeur peut définir un observer ? pourquoi pas.
        • Dans ce cas de figure il faudra limiter le nombre de personne d'un certain type (receiver, lastupdater) ou pas. Dans ce cas il ne faut peut-être pas les gérer avec cette table.

Mise en place :

  • Création tables
    • table glpi_groups_tickets : id, tickets_id, groups_id, type(requester/assign) OK
    • table glpi_tickets_users : id, tickets_id, users_id, use_notification, alternative_mail, type (requester/assign/observer) OK
  • Migration des données
    • Migration des données de Ticket : simple OK
    • Migration des templates de notifications : 2 possibilités
      • remplacer les appels à ##ticket.assigntouser## et équivalents par une boucle sur tous les users OK
      • Walid : je suis d'accord. Si c'est un champs multi-valués, alors boucle foreach
      • Garder ce tag qui liste tous les users
      • Walid : je pense qu'il vaut mieux l'enlever
        • MoYo : c'est un tag simple alors que mettre une boucle ne semble pas évident. Rendre les 2 possible permettrait d'avoir un affichage simple via le tag simple et de pouvoir faire plus complet via la boucle ?
        • Walid : ok pour moi. Soit prévoir un commentaire dans la liste des TAGs pour le préciser, soit voir à rajouter ça juste dans la doc
  • Modification du getFromDB de Ticket pour permettre la récupération des utilisateurs et groupes rattachés : stockage dans des variables de l'objet OK
    • Nécessite d'ajouter une fonction à CommonDBTM : post_getFromDB OK
      • Walid : tu mets quoi dedans ?
      • MoYo : récupération des utilisateurs et groupes liés un peu comme on fait pour les règles pour récupérer les actions et critères mais dans une fonction spéciale. Mais dans ce cas je pense que la récupération doit être automatique car elle influe sur les droits.
  • Adaptation du moteur de recherche : pas compliqué OK
  • Notifications
    • Ajouter notion d'observer OK
    • Modifier la gestion des destinataires. OK
  • Clean stats OK