Forum GLPI-Project

tristan.gallet

Member

Registered: 2010-02-02

Posts: 26

Changement du cycle de vie des tickets

Bonjour à tous,

Je viens d'installer la derniière version de GLPI (0.84.7) et en testant les tickets, il me semble que le workflow des tickets ne cadre pas avec certaines utilisations.

Par exemple, lors de la création d'un ticket, celui-ci passe à l'état nouveau : -> ok

Par contre, si l'on fait une règle métier pour l'attribuer à un groupe, le ticket passe à l'état : en cours (attribué).

Or en réalité, le ticket n'est pas encore pris en compte par quelqu'un du groupe, il devrait donc plutôt être dans un statut (Nouveau -> attribué) ou rester dans le statut nouveau.

Cela fausse les stats puisque tous les tickets du groupe sont déjà en cours -> ce qui en ITIL siginfie que l'on est en train de travailler dessus, ce qui est faux dans ce cas.

Pour moi, le gros manque de Glpi est clairement le côté Workflow non modifiable, un très bon exemple est Redmine qui permet une grande souplesse avec gestion du Workflow et des droits en fonction des files.

Ce côté gestion de ticket est il en prévision dans vos développements ?

Merci en tout cas pour ce bel outil !

LaDenrée

HELPER

Registered: 2012-11-19

Posts: 6,280

Re: Changement du cycle de vie des tickets

Bonjour,
Dès que le ticket est attribué à un groupe, il est sensé pouvoir travailler dessus, il me semble normal de déclencher le chrono. Pendant ce temps l'utilisateur attend sa solution. pour arreter le chrono, il faut mettre en attente.
Je dirais qu'on peu laisser au statut nouveau lorqu'un "client" a demandé une intervention mais qu'il n'a pas fourni suffisament d'informations pour commencer à traiter son ticket. dans ce cas le delai est imputable au client et on peut arreter le chrono.
Si vous voulez laisser le ticket à nouveau il ne faut pas l'attribuer, sinon il passe à attribué.

j'aime bien ce fonctionnement où le chrono tourne tant que le client attend sa solution (sauf si on attend une réponse de sa part).
C'est ma vision des choses mais ce n'est pas forcément la seule vérité.

---

Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1  Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9

tristan.gallet

Member

Registered: 2010-02-02

Posts: 26

Re: Changement du cycle de vie des tickets

En fait, il s'agit d'avoir une granularité plus fine : par exemple dans le cas de SLA soumis à pénalités.

Dans les fait, on a souvent un Front office qui surveille l'arrivée des tickets dans une ou plusieurs files, dans ce cas, le statut est bien à nouveau mais attribuée à une file, ce que j'ai implémenté, peut être à tord à un groupe afin d'obtenir un mail pour les membres du groupe à l'arrivée du ticket.

Avec d'autres outils, on a par exemple le statut : take in charge : qui signifie en gros qu'une personne du Front l'a vu et va faire un pré-traitement (en général on l'assigne au Front Office ou au MIDDLE ou renvoie à une autre file).

Cette prise en charge est souvent passible de SLA, différent du temps de résolution du ticket (EX : SLA de prise en charge : 15minute, résolution de 10h).

Par contre, effectivement, on ne peut pas assigner un ticket à un groupe et ensuite remettre le statut à nouveau via les règles métiers, cela ne fonctionne pas malgré le test qui dit que c'est ok.

C'est effectivement difficile d'avoir un fonctionnement uniforme, c'est pouquoi ça serait intéressant de pouvoir gérer cela soi-même

Bonjour,
Dès que le ticket est attribué à un groupe, il est sensé pouvoir travailler dessus, il me semble normal de déclencher le chrono. Pendant ce temps l'utilisateur attend sa solution. pour arreter le chrono, il faut mettre en attente.
Je dirais qu'on peu laisser au statut nouveau lorqu'un "client" a demandé une intervention mais qu'il n'a pas fourni suffisament d'informations pour commencer à traiter son ticket. dans ce cas le delai est imputable au client et on peut arreter le chrono.
Si vous voulez laisser le ticket à nouveau il ne faut pas l'attribuer, sinon il passe à attribué.

j'aime bien ce fonctionnement où le chrono tourne tant que le client attend sa solution (sauf si on attend une réponse de sa part).
C'est ma vision des choses mais ce n'est pas forcément la seule vérité.

yllen

GLPI-DEV

From: Sillery (51)

Registered: 2008-01-14

Posts: 15,278

Re: Changement du cycle de vie des tickets

Si vous voulez que le groupe soit notifié sans changer le statut, il faut, via vos règles métier, affecter un groupe Observateur.

---

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)

tristan.gallet

Member

Registered: 2010-02-02

Posts: 26

Re: Changement du cycle de vie des tickets

Merci, effectivement comme cela ça fonctionne.  Ca induit que la personne qui prenne le ticket l'attribue ensuite à un groupe, mais ça répond au besoin.

Bonne journée.