You are not logged in.
Bonjour à tous,
J'ai déjà lu des sujets dans la base, mais pas de réponse satisfaisante à mes yeux, à moins que je n'ai pas du tout la même définition d'une tache que l'équipe de dev.
Pour moi, une tache est un élément unitaire de réalisation ou de résolution. De fait, une tache est planifiée ou non, faite ou à faire. SI elle est à faire, alors elle est planifiable. Si elle est faite, alors qu'elle n'est pas planifié ... la date ne peut être qu'antérieure à maintenant. Non?
Il est courant qu'une tache soit créée après sa réalisation pour l'historique, la facturation ou le calcul du coût ou des statistiques diverses. Par exemple, si j'ouvre un ticket au téléphone et que je réalise plusieurs taches, je vais régulariser après. Cela fait donc bizarre de devoir planifier des trucs avec une date/heure antérieure à maintenant, qui plus est pour dire que c'est fait. D'ailleurs, si c'est marqué comme fait, cela ne devrait plus être planifiable, non?
Dans le même topo, lorsqu'on rempli le ticket et qu'on donne un temps de réalisation (donc à priori le ticket est soldé, mais on peut imaginer qu'il y a encore du boulot a faire), pourquoi y a t il la création d'une tache vide avec la durée totale, mais pas de description et pas fini?
Mais tout ceci doit avoir une explication que ma propre logique et habitude ne voit pas. Donc, une petite explication pour permettre une meileure utilisation.
Très beau boulot quand meme. Continuer, c'est superbe
Offline
Bon je vais essayer de répondre à vos interrogations.
Concernant la planification d'un tâche à faire, elle est laissée pour pouvoir indiquer la date réelle de la réalisation, la tâche en elle-même prenant la date de sa création.
Concernant le champ Durée proposé à la création d'un ticket, il sert a indiquer la temps réel de travail sur le ticket. Cela correspond à la création d'une tâche, vu que seule cette option permet d'ajouter un temps à un ticket.
Cette option sert pour ajouter le premier travail effectué sur un ticket lors de la création de celui-cio a posteriori et pas uniquement pour créer des tickets au statut Résolu ou Clos.
La logique qu'utilisent les développeurs vient beaucoup des demandes des utilisateurs et le problème est de combiner toutes les demandes afin que les utilisateurs de GLPI retrouvent leurs pratiques locales.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
OK. C'est le processus que vous avez mis en place.
Donc, si j'ai bien compris. Le temps sur l'ouverture du ticket correspond au temps passé à ouvrir le ticket. Celui-ci (s'il est renseigné) génère une tache correspondant à ce temps passé pour la création de tache. Il serait sympa de mettre une information par défaut du style "Création du ticket/Résolution simple" ainsi qu'une catégorie permettant d'éviter toute ambiguïté sur cette tâche créée automatiquement. Mais ce n'est que mon avis.
Par contre, si j'ai bien compris le mécanisme à l'origine de cette tâche sans description, alors pourquoi la tâche est-elle marquée "A faire" ?
Autre point, si cela sert lors d'un ticket à posteriori, alors pourquoi la date de la tâche est-elle celle courante et non celle du ticket, si elle correspond à la création du ticket ou à une création à postériori ou une cloture simultanée à la création (pour cette dernière les 2 sont identiques ou presque). ? Cf mon autre post sur le sujet.
Mais cela doit avoir une explication logique que je perçois pas.
Offline