You are not logged in.
Pages: 1
Topic closed
date de fin de SLA erronée après mise en attente d'un ticket ayant un SLA en jour et un calendrier
bonjour,
le scénario est le suivant: j'ai des SLA de plusieurs jours (2 jours, 5 jours, etc.) associées à un calendrier (dimanche et jours fériés non-travaillés); si je met un ticket ayant un SLA de plusieurs jours en attente et que je le réactive après un ou plusieurs jours non-travaillés, la fin du SLA est recalculée mais les jours non-travaillés sont ajoutés deux fois pour calculer la nouvelle date de fin de SLA.
exemple: un ticket avec un SLA de 2 jours, fin théorique le vendredi, mis en attente le jeudi (un jour consommé, reste 1 jour) et réactivé le lundi à un reste de temps de 3 jours au lieu de 1 jour.
dans le source de la 0.84.7 que j'utilise actuellement,
commonitilobject.class.php, lignes 934-942,
if (isset($this->fields['slas_id']) && ($this->fields['slas_id'] > 0)) {
$sla = new SLA();
if ($sla->getFromDB($this->fields['slas_id'])) {
$sla->setTicketCalendar($calendars_id);
$delay_time_sla = $sla->getActiveTimeBetween($this->fields['begin_waiting_date'],
$_SESSION["glpi_currenttime"]);
$this->updates[] = "sla_waiting_duration";
$this->fields["sla_waiting_duration"] += $delay_time_sla;
}
sla.class.php, lignes 328-334,
$work_in_days = ($this->fields['resolution_time'] >= DAY_TIMESTAMP);
// Based on a calendar
if ($this->fields['calendars_id'] > 0) {
if ($cal->getFromDB($this->fields['calendars_id'])) {
return $cal->getActiveTimeBetween($start, $end, $work_in_days);
}
calendar.class.php, lignes 268-271,
if ($work_in_days) {
$activetime = $timeend-$timestart;
} else {
le sla_waiting_duration est donc calculé par soustraction fin-début. puis:
commonitilobject.class.php, lignes 945-947,
// Compute new due date
$this->updates[] = "due_date";
$this->fields['due_date'] = $sla->computeDueDate($this->fields['date'],
$this->fields["sla_waiting_duration"]);
sla.class.php, lignes 250-259
if ($this->fields['calendars_id'] > 0) {
$cal = new Calendar();
$work_in_days = ($this->fields['resolution_time'] >= DAY_TIMESTAMP);
if ($cal->getFromDB($this->fields['calendars_id'])) {
return $cal->computeEndDate($start_date,
$this->fields['resolution_time']+$additional_delay,
$work_in_days);
}
}
calendar.class.php, lignes 353-397,
if ($work_in_days) { // only based on days
$cache_duration = $this->getDurationsCache();
// Compute Real starting time
// If day is an holiday must start on the begin of next working day
$actualdate = date('Y-m-d',$actualtime);
$dayofweek = self::getDayNumberInWeek($actualtime);
if ($this->isHoliday($actualdate)
|| ($cache_duration[$dayofweek] == 0)) {
while ($this->isHoliday($actualdate)
|| ($cache_duration[$dayofweek] == 0)) {
$actualtime += DAY_TIMESTAMP;
$actualdate = date('Y-m-d',$actualtime);
$dayofweek = self::getDayNumberInWeek($actualtime);
}
$firstworkhour = CalendarSegment::getFirstWorkingHour($this->fields['id'],
$dayofweek);
$actualtime = strtotime($actualdate.' '.$firstworkhour);
}
while ($delay > 0) {
// Begin next day : do not take into account first day : must finish to a working day
$actualtime += DAY_TIMESTAMP;
$actualdate = date('Y-m-d',$actualtime);
$dayofweek = self::getDayNumberInWeek($actualtime);
if (!$this->isHoliday($actualdate)
&& ($cache_duration[$dayofweek] > 0)) {
$delay -= DAY_TIMESTAMP;
}
if ($delay < 0) { // delay done : if < 0 delete hours
$actualtime += $delay;
}
}
// If > last working hour set last working hour
$dayofweek = self::getDayNumberInWeek($actualtime);
$lastworkinghour = CalendarSegment::getLastWorkingHour($this->fields['id'], $dayofweek);
if ($lastworkinghour< date('H:i:s', $actualtime)) {
$actualtime = strtotime(date('Y-m-d',$actualtime).' '.$lastworkinghour);
}
return date('Y-m-d H:i:s', $actualtime);
}
la nouvelle due_date est calculée en sautant les jours non-travaillés du calendrier, d'où le décalage.
comme je suis en train de migrer vers la version 9.2.2 j'ai jeté un rapide coup d’œil sur le source et le problème semble toujours présent (je dis semble car je n'ai pas encore fait de test pour vérifier)
commonitilobject.class.php, lignes 1070-1076,
if ($sla->getFromDB($this->fields['slas_ttr_id'])) {
$sla->setTicketCalendar($calendars_id);
$delay_time_sla = $sla->getActiveTimeBetween($this->fields['begin_waiting_date'],
$_SESSION["glpi_currenttime"]);
$this->updates[] = "sla_waiting_duration";
$this->fields["sla_waiting_duration"] += $delay_time_sla;
}
sla.class.php, ligne 45
class SLA extends LevelAgreement {
levelagreement.class.php, lignes 808-816,
$work_in_days = ($this->fields['definition_time'] == 'day');
// Based on a calendar
if ($this->fields['calendars_id'] > 0) {
if ($cal->getFromDB($this->fields['calendars_id'])) {
return $cal->getActiveTimeBetween($start, $end, $work_in_days);
}
} else { // No calendar
calendar.class.php, lignes 307-310,
if ($work_in_days) {
$activetime = $timeend-$timestart;
} else {
le sla_waiting_duration est toujours calculé comme fin-debut. puis,
commonitilobject.class.php, lignes 1078-1081,
// Compute new time_to_resolve
$this->updates[] = "time_to_resolve";
$this->fields['time_to_resolve'] = $sla->computeDate($this->fields['date'],
$this->fields["sla_waiting_duration"]);
sla.class.php, ligne 45
class SLA extends LevelAgreement {
levelagreement.class.php, lignes 840-849,
if ($this->fields['calendars_id'] > 0) {
$cal = new Calendar();
$work_in_days = ($this->fields['definition_time'] == 'day');
if ($cal->getFromDB($this->fields['calendars_id'])) {
return $cal->computeEndDate($start_date, $delay,
$additional_delay, $work_in_days,
$this->fields['end_of_working_day']);
}
}
calendar.class.php, lignes 463-507,
if ($work_in_days) { // only based on days
$cache_duration = $this->getDurationsCache();
// Compute Real starting time
// If day is an holiday must start on the begin of next working day
$actualdate = date('Y-m-d', $actualtime);
$dayofweek = self::getDayNumberInWeek($actualtime);
if ($this->isHoliday($actualdate)
|| ($cache_duration[$dayofweek] == 0)) {
while ($this->isHoliday($actualdate)
|| ($cache_duration[$dayofweek] == 0)) {
$actualtime += DAY_TIMESTAMP;
$actualdate = date('Y-m-d', $actualtime);
$dayofweek = self::getDayNumberInWeek($actualtime);
}
$firstworkhour = CalendarSegment::getFirstWorkingHour($this->fields['id'],
$dayofweek);
$actualtime = strtotime($actualdate.' '.$firstworkhour);
}
while ($delay > 0) {
// Begin next day : do not take into account first day : must finish to a working day
$actualtime += DAY_TIMESTAMP;
$actualdate = date('Y-m-d', $actualtime);
$dayofweek = self::getDayNumberInWeek($actualtime);
if (!$this->isHoliday($actualdate)
&& ($cache_duration[$dayofweek] > 0)) {
$delay -= DAY_TIMESTAMP;
}
if ($delay < 0) { // delay done : if < 0 delete hours
$actualtime += $delay;
}
}
// If > last working hour set last working hour
$dayofweek = self::getDayNumberInWeek($actualtime);
$lastworkinghour = CalendarSegment::getLastWorkingHour($this->fields['id'], $dayofweek);
if ($lastworkinghour < date('H:i:s', $actualtime)) {
$actualtime = strtotime(date('Y-m-d', $actualtime).' '.$lastworkinghour);
}
return date('Y-m-d H:i:s', $actualtime);
}
le time_to_resolve est calculé en sautant les jours non travaillés du calendrier.
Offline
Le système a complètement change en 9.2.x avec les SLM, les OLA...
Je viens de faire un test avec la dernière version
Ticket créé le mardi 03/04/2018 avec SLA 3 jours => date de résolution vendredi 06/04/2018
Calendrier tous les jours ouvrés
Ticket mis en attente le jeudi 05/04/2018 - réactivé le lundi 09/04/2018
Le delai d'attente à bien pris en compte le calendrier associé et n'a donc compté que 2 jours.
ces 2 jours ont été ajoutés au premier délai de résolution, soit 06/04/2018 + 2 jours => 08/04/2018
le 08/04/2018 étant un dimanche => 09/04/2018 première heure de ma plage horaire
Oui je sais, j'arrive à faire des tests avec des dates du futures... c'est l'avantage de bien connaitre GLPI, on peut simuler...
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 moi mon soucis
j ai un sla 4h temps de résolution si je creee un ticket il me met une erronne
exemple :ticket 28/11/2018 20h00 sla de 4h date indique 12/11/2026 12h00
merci de ton aide
Offline
tu as quelle version de glpi maintenant ?
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
la 9.2.3
on a migre de la 8.4.5 vers la 9.16 puis la 9.2.3
idem en 9.2.4
je n ai plus d idee
merci
Offline
apres migration de la 8.4.5 vers 9.1.6 impossible d affecter une regle metier à un niveau de service (sla)
apres en 9.1.6 la date des sla est correct mais toujours impossible d affecter une regle metier à un niveau de service (sla)
apres passage en 9.2.3 la date est erronée et toujours impossible d affecter une regle metier à un niveau de service (sla), de plus un des niveau de service ne voit plus sa regle mais en phpmyadmin elle est bien affecte (avant les bidouilles ca marchait)
le fait de ne pas pouvoir acceder au regle depuis les slas m enpechent d en creer d autres
dans phpmyadmin , pas de difference sur la 9.1.6 et 9.2.3 dans les tables , les champs sont identiques et les donnees
la 8.4.5 je ne l ai plus
merci par avance
Offline
bonjour j ai compris pourquoi je ne pouvais pas affecter une regle a un niveau de services
il me reste juste ce probleme de date sur les slas qui n y est pas en 9.1.6 juste en 9.2.3 ou 9.2.4
merci
Offline
merci probleme regle
un jour ferie etait du 1/05/2016 au 01/05/2026
Offline
Merci du retour, je clos
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
Pages: 1
Topic closed