You are not logged in.
Pages: 1
I'm using GLPI 9.1.2 and have come across this strange bug.
This has only happened once so far, in one ticket. One of the tasks posted in the ticket gets constantly displayed at the very top, although the date is not the newest. The task has the date of 28-06-2017 18:21, right beneath it, a follow-up with the date of 18-07-2017 09:33 (newer) is shown.
I've tried to find out why this has happened and so far I can see why it's displayed at the top: in the database, I can see that the ticket task has a date of 2017-08-21 10:00:00 (in the future). I've fixed the date manually for now.
Does anybody have a hint why this date got saved instead of the real date?
Offline
You can change manually the date of a ticket task.
Look at Historical tab
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
I've already changed the date, that's not the problem. I'm asking why an incorrect date got registered in the first place.
Offline
What is written in the historical tab?
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
I have a similar problem with 9.1.6. Whenever I create a ticket GLPI assigns (by default) a time seven hours later. Here are the contents of my history tab:
ID Date User Field Update
643 29-08-2017 03:08 glpi (2) Resolution date Change to 29-08-2017 03:08
642 29-08-2017 03:08 glpi (2) Closing date Change to 29-08-2017 03:08
641 29-08-2017 03:08 glpi (2) Status Change Processing (assigned) to Closed
640 29-08-2017 03:08 glpi (2) Solution Update of the field
639 29-08-2017 03:08 glpi (2) Description Update of the field
637 29-08-2017 03:05 glpi (2) Computer Add a link with an item: PC Vera (12)
636 29-08-2017 03:05 glpi (2) Last update Change 29-08-2017 03:05 to 29-08-2017 03:05
634 29-08-2017 03:05 glpi (2) Computer Add a link with an item: PC Biblioteca (14)
633 29-08-2017 03:05 glpi (2) Last update Change 29-08-2017 03:04 to 29-08-2017 03:05
632 29-08-2017 03:04 glpi (2) Add the item
631 29-08-2017 03:04 glpi (2) User Add a link with an item: glpi (2) (Assigned to)
630 29-08-2017 03:04 glpi (2) Take into account time Change 0 seconds to 1 minute
629 29-08-2017 03:04 glpi (2) User Add a link with an item: glpi (2) (Assigned to)
I'm using GLPI on a QNAP TS-253A with QTS 4.3.3
Edit: Looked in the logs, all events have a timestamp seven hours after the real time
Last edited by Moody_Blue (2017-08-29 00:26:54)
Offline
Your server has the good time?
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
Your server has the good time?
Yes it has, both in the command line and in the operating system UI.
Offline
I've discovered how to fix the problem. I've edited php.ini and php.user.ini files to change field date.timezone to my timezone. Probably it's better that glpi picks the system date for log timestamps and allows each user to specify his/her timezone for tickets (and other tasks).
More info here -> http://forum.qnapclub.fr/topic/3700-dat … dules_etc/
Last edited by Moody_Blue (2017-08-30 12:26:10)
Offline
Pages: 1