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