You are not logged in.

Announcement

 Téléchargez la dernière version stable de GLPI      -     Et vous, que pouvez vous faire pour le projet GLPI ? :  Contribuer
 Download last stable version of GLPI                      -     What can you do for GLPI ? :  Contribute

#1 2018-02-02 12:34:10

stournier
Guest
Registered: 2005-03-08
Posts: 160

Date résolution, eviter effacement au changement de statut ?

Bonjour, dans le cadre de nos statistiques de prise en compte de tickets, nous devons faire une certaine première action pour que cela soit pris en compte.

Ex : Une personne a un problème pour imprimer.
Il faut que l'on regarde l'état des imprimantes et voir pourquoi cela ne s'est pas imprimé.

Dès que l'on a fait cela on peut mettre le ticket en résolu, par contre si quelqu'un répond au mail de glpi, cela créér un suivi et remet le statut en cours attribué, mais cela enlève la date de résolu.

Donc est ce qu'il y a un moyen perenne ou a faire a chaque MAJ de glpi, pour que la date de résolution ne s'enlève pas a chaque action ?

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#2 2018-02-02 14:31:31

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

bonjour,
ce n'est à mon avis pas une bonne idée de passer le ticket en résolu si vous n'avez pas terminé.
si j'ai bien compris votre besoin c'est de marquer la date de prise en charge, (glpi enregistre la date de prise en charge mais tout le monde n'a pas la même définition de "prise en charge"), vous pouvez ajouter une tâche de catégorie "prise en charge" comme ça vous conservez la date l'action ,l'acteur, de la prise en charge.

dans votre exemple, vous faites un diagnostic, et après ? ce qui interresse l'utilisateur c'est que son imprimante imprime. 
Dans peu de temps  vous aurez besoin d'enregistrer la date ou vous avez indiqué à l'utilisateur que ça remarche, et vous aurez besoin de la date de résolution. voilà pourquoi je pense qu'il faut éviter de détourner l'utilisation.  Si vous mesurez les temps de prise en charge, c'est que vous vous engagez dans une démarche qualité, qui ne va pas s'arreter là et vous aurez besoin de mesurer le temps de résolution.


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#3 2018-02-02 16:01:59

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

Bonjour, merci de la réponse, c'est vrai que cela peut le faire, mais par contre, notre souci, c'est comment mesurer le temps entre l'ouverture de la demande de ticket et la tache avec categorie pris en charge ?

Car on ne doit pas dépasser 70% sur l'ensemble de nos tickets, donc on a besoin de calculer cela.

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#4 2018-02-02 16:04:09

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

70% de quoi ?


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#5 2018-02-02 16:56:37

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

70% des tickets doivent être pris en compte avant les 8h.

Et je me demande si on peut aussi faire ces stats par type de ticket incident/ demande plutot que les deux.

Car on pourrait avoir une prise en compte plus longue pour les demande.

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#6 2018-02-02 17:04:35

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

1) vous pouvez creer 2 slt de prise en charge  1 slt prise en charge incident et un slt prise en charge demandes.
2) vous creez une règle métier pour les tickets qui affecte le slt en focntion du type, vous aurez ainsi pour chaque ticket une date cible maxi de prise en charge.

3) avec le plugin rapport  vous pouvez comparer la date cible de prise en charge avec la date de la tache . 
la requête sql est un peu tordue mais ça marche bien.

vous devez définir avant si vous considérez qu'un ticket résolu en moins de 8h doit être pris en charge.


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#7 2018-02-02 17:15:33

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

pour info , j'ai fait la requète avec les suivis ( j'ai choisi un suivi dont la source est 9, comme ça en plus de la prise en charge j'envoie une notification au client en une seule etape, mais on peut changer pour une tâche).
je considèreque si le ticket est résolu avant l'engagement de prise en charge il est conforme.
les premières colonnes affichent l'id et nom ticket, puis la date cible de prise en charge, la reelle de prise en charge ( suivi), le nombre de jour entre ouverture et cible, nombre de jour entre ouverture et pec reelle, et après c'est des formules pour affiche conforme en vert dans le rapport ou le nombre de jour de dépassement.

j'affiche aussi le groupe en charge du ticket.




$query = "SELECT `glpi_tickets`.`id` AS ID
	, `glpi_tickets`.`name` AS titre
	,`glpi_slts`.`name` AS slt
	, `glpi_tickets`.time_to_own AS tto
	,  CASE WHEN DATEDIFF(`glpi_tickets`.solvedate,`glpi_tickets`.time_to_own) <1 then `glpi_tickets`.solvedate 
		ELSE IFNULL(FU.date,NOW())
		END AS pec
	,`glpi_groups_tickets`.groups_id as groupe	
	, DATEDIFF(`glpi_tickets`.time_to_own,`glpi_tickets`.date) AS gti
	, DATEDIFF(	CASE WHEN DATEDIFF(`glpi_tickets`.solvedate,`glpi_tickets`.time_to_own) <1 then `glpi_tickets`.solvedate 
			ELSE IFNULL(FU.date,NOW())
			END
		,`glpi_tickets`.date)  AS delai

	,  
CASE
    	WHEN  DATEDIFF(	CASE WHEN DATEDIFF(`glpi_tickets`.solvedate,`glpi_tickets`.time_to_own) <1 
			THEN `glpi_tickets`.solvedate 
			ELSE IFNULL(FU.date,NOW()) 
			END ,
			`glpi_tickets`.time_to_own)<0   
	THEN '<font color=green><b>Conforme</b></font>' 
	ELSE CONCAT( '<font color=red><b>+', DATEDIFF(
							CASE 
							WHEN DATEDIFF(`glpi_tickets`.solvedate,`glpi_tickets`.time_to_own) <1 
							THEN `glpi_tickets`.solvedate 
							ELSE IFNULL(FU.date,NOW())
							END
							,`glpi_tickets`.time_to_own)  
	      ,'</b></font>')
	END  AS depassement
";



$query .= " FROM `glpi_tickets`  ";
$query .= " JOIN `glpi_slts` ON `glpi_slts`.`id`=glpi_tickets.slts_tto_id "; 
$query .= " JOIN `glpi_groups_tickets` ON `glpi_groups_tickets`.tickets_id=`glpi_tickets`.id and `glpi_groups_tickets`.type=2";
$query .= " LEFT OUTER JOIN glpi_ticketfollowups AS FU on FU.tickets_id=`glpi_tickets`.`id` AND FU.requesttypes_id=9 ";
$query .= " WHERE `glpi_tickets`.`is_deleted` = '0' ";
$query .= $report->addSqlCriteriasRestriction();

$query .= " ORDER BY slt ";

Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#8 2018-02-02 17:20:06

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

qu'est qu'un slt ?


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#9 2018-02-02 17:23:06

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

Et pourquoi creer une regle qui affecte le slt ?


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#10 2018-02-02 17:26:15

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

dans glpi c'est un niveau de service cible,
vous définissez que slt8h correspond à un temps maxi de prise en charge de 8h ( ouvrée, calendaires, selon votre propre calendrier, entre 9 et 15h  comme vous voulez)

quand vous associez ce slt à un ticket, glpi calcule automatiquement la date cible de prise en charge qui s'affiche dans "temps de résolution".

ça s'appelait sla dans les verisons précédentes mais les sla etaient uniquement pour la résolution, maintenant il y a un slt de prise en charge, et un slt de resolution.


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#11 2018-02-02 17:27:51

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

la règle c'est pour que sur chaque ticket le champ "temps de prise en charge" soit complété.  (vous pouvez bien sur calculer pour chaque ticket, heure d'ouverture +8 et l'indiquer dans ce champ mais c'est moins pratique)
edit : bien s^rr vous pouvez dans vos stats faire heure+8 mais vous pensez dejà à avoir une autre valeur pour les demandes, ça va rapidement devenir ingérable alors qu'avec ces règles vous pouvez avoir 36 temps en fonction de la demande, du client, etc et le rapport de vérification du respect des temps de prise en charge fonctionne toujours.)


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#12 2018-02-02 17:39:15

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

D'accord, je commence a saisir, la j'ai créé un calendrier jours ouvré, après je vais chercher pour service, j'ai trouvé, je vais voir et cherche comment cela marche.

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#13 2018-02-02 17:50:00

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

J'ai pas compris la difference en SLA et OLA dans niveau de service, et dans les infos que j'ai trouvé, ce n'est pas assez clair, et les noms ont changé.

Pouvez vous m'expliquer ? Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#14 2018-02-02 17:53:57

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

Sla c'est ce que vous vendez au client final, vous semblez au début de votre démarche, je pense que c'est ce dont vous avez besoin. en 2eme etape pour pourrez utiliser les OLA  (OLA c'est entre vos techniciens/ interne à votre organisation pour vous aider à respecter vos SLA)


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#15 2018-02-02 18:13:09

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

D'accord, merci bien, je vais faire quelques test et voir avec toutes les infos que vous m'avez donné, merci beaucoup pour votre temps.


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#16 2018-02-02 18:19:44

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

Cool mon SLA a l'air de marcher, quand je créer un nouveau ticket en incident, cela met bien la date 8h après, donc ici +8h 05-02-2018 16:46

Par contre que se passe-t-il quand le délai de pris en charge est dépassé ?


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#17 2018-02-02 18:35:03

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

avec votre paramétrage il ne se passe rien. il existe des escalades qui déclenchent des action par rapport à ce délai mais : visiblement, dès que vous touchez au ticket, glpi considère qu'il est pris en charge ( à confirmer , je ne comprend pas bien ce fonctionnement) donc les actions ne se déclenchent pas.

donc cette date peut être utilisée vos indicateurs, et peut servir à vos techniciens à identifier les tickets à traiter.

est ce que vous attribuez le ticket à la creation ?

-pour le slt de résolution c'est plus simple car l'evenement est clairement défini : ajout de solution. donc les escalades ( changement de priorité automatique, mail d'alerte, au technicien, au superviseur, à la terre entière,  etc fonctionnent très bien)


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#18 2018-02-05 09:37:08

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

Bonjour, les tickets sont soit créé par le collecteur, soit pas nous depuis glpi.

Ensuite on créé une tache avec ce que l'on a fait pour essayer de résoudre la personne ou pour lui poser une question. Car pour chaque action on doit définir le temps.

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#19 2018-02-06 11:56:13

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

Par contre pour la requête, comment peut on faire pour exclure des tickets qui sont dans une certaine catégorie ?

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#20 2018-02-06 15:08:49

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

je ne vois pas trop où vous en êtes ?
est ce que les slt sont affectés automatiquement ? avec une règle ?


vous ne vous lez pas attribuer de slt pour certains tickets ?
ou alors êtes vous déjà sur le rapport ?


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#21 2018-02-08 17:38:20

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

Le SLT lors de la creation du ticket affiche bien la date 7h après.

Il faut que je regarde pour que cela ne soit attribué qu'a ceux en incident.

Et voir comment faire pour mettre le SLT 50h pour les demandes.

Ensuite pour le rapport j'ai un peu regarder, et il faut que je trouve comment faire un rapport avec les tickets en incident avec le calcul de la tache en moins de 7h.

Mais j'aimerai aussi faire des statistiques sur le nombre de ticket qui sont en résolu en un certain temps aussi.

Mais dans les tickets soit en demande soit en incident j'aimerai pouvoir exclure des catégories.

N'existe pas déjà des rapports dans ce sens ?

Ou une liste de requête ?

Merci


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#22 2018-02-08 18:21:15

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

Il faut que je regarde pour que cela ne soit attribué qu'a ceux en incident.

Et voir comment faire pour mettre le SLT 50h pour les demandes.

comment attribuez vous les SLT automatiquement ?
par une règle ?

une solution pour votre cas ( ce n'est peut être pas la meilleure) :
-créez un gabarit G_demandeavecSLT50  avec slt50h comme valeur prédéfinie pour le slt
-créez un gabarit G_IncidentavecSLT7  avec slt7h comme valeur prédéfinie pour le slt

dans configuration>intitulés>catégories>[ma catégorie]> attribuez le bon gabarit demande/incident  :   défaut(sans slt) ,G_demandeavecSLT50, ou G_IncidentavecSLT7


une autre solution utilisez les règles métier pour les tickets pour associer le slt en focntion du type demande/incident et des catégories à exclure
Règle R1 :
critere
si type=demande
ET catégorie n'est pas cat1
ET catégorie c'est pas cat2
ET catégorie n'est pas catx

action : Slt associer slt50

et idem pour incident
Règle R2 :
critere
si type=incident
.....


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#23 2018-02-08 18:26:16

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

Mais j'aimerai aussi faire des statistiques sur le nombre de ticket qui sont en résolu en un certain temps aussi.

idem que prise en charge : il faut identifier les tickets avec des slt de résolution .
sauf que pour la résolution vous avez un champ "date de résolution"  glpi_tickets.solvedate qui se remplit automatiquement. vous pouvez le comparer avec votre engagement SLT de résolution .


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

#24 2018-02-09 09:45:33

stournier
Guest
Registered: 2005-03-08
Posts: 160

Re: Date résolution, eviter effacement au changement de statut ?

D'accord merci, cela à l'air assez complexe, mais je vais regarder tout cela.  Merci pour les infos, j'espère que cela pourra aussi aider d'autres personnes pour bien utiliser le SLT et le plugins reports.

En tout cas pour nous, c'est surtout les rapports le plus important, car pour le SLT pour le moment on ne déclenche rien quand on dépasse.

Mais pour faire les rapports on a besoin de configurer les SLT ou c'est indépendant ?

Merci encore


GLPI 9.2.1 sur CentOS Linux release 7.2.1511 (Core) / OCS-NG 2.3 sur même machine
httpd-2.4.6-40.el7.centos.4.x86_64 / php-common-5.6.31-1.el7.remi.x86_64
PHP 5.6.31 (cli) (built: Jul  6 2017 08:06:11) / Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.50-1.el7_2.x86_64 / mariadb-server-5.5.50-1.el7_2.x86_64

Offline

#25 2018-02-09 10:02:13

LaDenrée
HELPER
Registered: 2012-11-19
Posts: 3,677

Re: Date résolution, eviter effacement au changement de statut ?

Les slt vont vous permettre d avoir des données correctes. Les rapports seront plus faciles et plus justes.
Ensuite si vous vouler ajouter des catégories changer les temps vous n aurez qu'à modifier les SLT sans refaire le rapport.
C est mon approche.  Ce n est pas la seule. Mais sur le long terme ça marche.

Donc vous avez vos tickets avez une date cible de prise en charge  une tâche de catégorie prise en charge  une date cible de résolution et une date de résolution.

Avec  ça on va pouvoir faire des stats.


Trouver la panne avant de réparer...
*GLPI 9.1.6+fusion9.1+1.1+behaviours1.5.0+reports+fields+appliances+pdf+badges+webservices PHP7.0 Mariadb10
*GLPI 9.2.1(behaviours1.5.2+fusion9.2+1.0+applicatifs2.3.0+dashboard 0.8.9)hebergé sur serveur mutualisé.

Offline

Board footer

Powered by FluxBB