Réflexions sur la cloture de ticket.

Séminaire

Modification des statuts

  • Le statut "Fermé" devient "Résolu". Un nouveau statuts "Clos" est ajouté.

Options de config

  • Clôture automatique : Jamais -> au bout de X jours
  • Par entité

Droits

  • Droit supplémentaire pour le central : clore (tous) les tickets (et donc réouverture)
  • les demandeurs ou groupes demandeurs disposent de ce droit implicite pour leurs requêtes

Comportement

  • Passage à l'état "Résolu" demande une demande d'approbation
  • Passage à l'état "Clos" déclenche une notification de clôture du ticket

Modification de l'interface

  • Post-only :
    • liste des tickets en attente d'approbation (tickets résolus soumis à votre approbation)
    • 2 boutons :
      • accepter la solution -> statut = clos
      • refuser la solution (saisie d'un commentaire obligatoire) : retour au statut "En cours"
        • Faire attention à ne pas envoyer 2 notifications pour le changement de statut et le refus de l'approbation
  • Central :
    • Dans onglet résolution : choix du nouveau statut pour le ticket
      • Ajout préférence utilisateur pour statut à la résolution par défaut

----
Réflexion initiale

ITIL indique que la cloture administrative d'un ticket ne doit être possible qu'aprés validation par le demandeur. Ceci n'est pas lié directement à la problématique des enquêtes de satisfaction (cf chantiers en cours).

Système envisageable comprenant deux options :

Cloture manuelle : c'est le technicien qui clôt le ticket lui même après l'avoir résolu.

Cloture automatique d'une requête aprés X jours (configurable)

  • Un email est adressé au demandeur lorsque le ticket est résolu
  • Le demandeur peut accepter de clore la requête par l'intermédiaire du lien communiqué, ou rouvrir la requête en répondant à l'e-mail ou en postant un nouveau suivi
  • Lorsque le demandeur ne se manifeste pas, la requête est close après le délai de X jours