You are not logged in.
Pages: 1
Dans le module helpdesk, nous aimerions ajouter un champ "cause" au ticket, qui serait uniquement éditable par la personne qui résoud l'incident.
La cause est du type "user error" "software error" "hardware error", etc.
Ca permet de tirer des statistiques, et donc d'améliorer le fonctionnement interne. Par exemple, en cas de nombreux "user error" sur un logiciel en particulier, on pourrait prévoir une formation sur le logiciel en question.
Comment pourrais-je faire? Quelles sont les options?
Merci.
Laurent.
Offline
coder un plugin qui permette d'afficher ça ou attendre la prochaine version
Offline
La prochaine version intègrera-t-elle bien cette fonctionnalité? Pour quand est-ce prévu?
Merci,
Laurent
Offline
y a encore beaucoup de travail dessus, pas avant l'année prochaine, ça c'est sur
Offline
Bonjour,
J'ai retroussé mes manches pour implémenter la fonction moi-même:
- Création d'une dropdown pour pouvoir customiser la liste des causes possibles d'un ticket
- Modification du tracking pour pouvoir assigner et modifier la cause d'un ticket.
- Le "search" au niveau tracking a également été modifié en conséquence, ainsi que les e-mails de status
Ca a l'air de fonctionner.
Comment puis-je mettre le code à disposition pour intégration (si c'est jugé utile) dans le produit?
Si on me donne les droits de dévelopement, je peux également réintroduire la fonctionalité moi-même dans le produit.
Pouvez-vous me dire comment procéder?
Merci,
Laurent.
Offline
Salut,
Nous on utilise la catégorie du ticket pour stocker cette cause. Pas jouable chez vous ?
Ubuntu 9.04 (jaunty) - sous VMWare
GNOME 2.26.1
Apache 2.2.11 - MySQL 5.0.75 - PHP 5.2.6
GLPI 0.72.1 / OCS Inventory NG 1.02
Offline
La catégorie ne suffit pas dans notre cas.
La catégorie indique le type de demande (incident, demande de service, demande de consommables, demande d'achat de matériel, etc).
La cause indique plutôt le fait que la demande résulte d'un besoin, d'une erreur humaine, etc.
La catégorie est assignée par le demandeur.
La cause est déterminée par le helpdeskeur.
Cette différenciation est importante pour nous. Elle permet une analyse à postériori des tickets, et de déterminer les actions à prendre pour améliorer la situation dans le futur.
Exemples:
Si on a beaucoup de tickets dont la catégorie est "incident" et la cause est une erreur humaine pour un logiciel déterminé, on peut en tirer un besoin de formation.
si on a beaucoup de tickets dont la catégorie est "inicident", mais la cause est une erreur de logiciel, cela indique une faiblesse dans la réalisation du logiciel, et on peut ainsi envisager un re-engineering de l'applicatif mis en cause.
Offline
La version 0.80 prévoit
- catégorie du ticket (du problème)
- catégorie des taches (opérations mis en oeuvre)
- catégorie de solution
ça devrait le faire, non ?
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
En fait, il me semble que tous ces champs ont le même rôle, à savoir catégoriser les tickets d'une façon ou d'une autre en fonction d'un besoin particulier.
Ce sont en fait des meta-data du ticket, dont les valeurs sont limitées à une liste définie par l'administrateur.
En fonction des utilisations, on peut utiliser ces champs pour une raison ou une autre. Dans mon cas, le champ servira à mettre la cause d'un ticket, mais dans un autre cas, on pourrait imaginer que le même champ soit intitulé différemment et serve à autre chose.
L'idéal, finalement, serait peut-être d'avoir des champs génériques (disons 3) dont l'intitulé et donc la signification pour l'utilisateur pourrait être configurable.
Ces 3 champs "meta data", pourraient être configurables comme suit:
- Utilisation ou non du champ (inutile d'en mettre 3 si on n'en n'a pas besoin, ça évite de surcharger la "tracking list").
- Intitulé (on pourrait le laisser à "meta data" par défaut, et libre à l'utilisateur de le changer au niveau des "locales").
- Liste des valeurs qu'il peut prendre (définition de la dropdown correspondant)
- Visibilité ou non dans l'interface de soumission de tickets (champs éditables par le demandeur ou uniquement par le helpdeskeur).
Ceci dit, ayant déjà fait l'effort pour un champ (mon champ "cause", que je peux renommer "catégorie de solution" pour m'aligner avec votre nomenclature, libre à moi de modifier l'intitulé dans les locales), peut-on anticiper l'intégration de la fonction? Je peux m'en charger si vous le désirez, ou mettre mon code à disposition.
J'ai remarqué au passage, un autre post dont la demande est presque identique http://www.glpi-project.org/forum/viewt … p?id=17413 et rentre parfaitement dans ce cadre-ci.
bien à vous,
Laurent
Offline
J'ai implémenté la fonction en question.
J'essaie en vain d'envoyer mes patches sur la liste de diffusion des dévelopeurs. Sans succès.
Quelqu'un peut-il me conseiller là dessus?
Offline
Il faut s'abonner à la liste de diffusion afin de pouvoir y poster un message
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Ben, j'ai fait ça, mais rien n'arrive sur la liste quand je poste...
Offline
OK, j'y suis enfin parvenu. Les patches sont donc disponibles sur la liste de diffusion.
J'espère que les dévelopeurs pourront le reprendre dans le "trunk".
Offline
amigos alguien a mejorado el campo categorias,
ya que tengo muchas categorias y quiere buscar la formar de hacer otro selector
Offline
Pages: 1