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
- Dans onglet résolution : choix du nouveau statut pour le ticket
----
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