Closed jcervantes-sipecom closed 3 years ago
tomolimo
commented
4 years ago Hello @jcervantes-sipecom
I know this bug 😃
It's a bug in MariaDB when changing the DATETIME fields into TIMESTAMP, see: https://github.com/tomolimo/timezones/issues/16 and https://github.com/tomolimo/timezones/issues/24
I had also this issue in the Timezones plugin...
The only way is to edit the default values for the TIMESTAMP fields and to set them to NULL
Thank you Regards, Tomolimo
jcervantes-sipecom
commented
4 years ago @tomolimo thank you so much for your soon reply, I read the 2 links you post, and you were right, I got some fields with that values:
show columns from glpi_tickets where `Default`= '2038-01-18 22:14:07';
+--------------------------+-----------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------------------+-----------+------+-----+---------------------+-------+
| date | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| closedate | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| solvedate | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| date_mod | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| time_to_resolve | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| time_to_own | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| begin_waiting_date | timestamp | YES | | 2038-01-18 22:14:07 | |
| internal_time_to_resolve | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| internal_time_to_own | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| date_creation | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
+--------------------------+-----------+------+-----+---------------------+-------+show columns from glpi_tickettasks where `Default`= '2038-01-18 22:14:07';
+---------------+-----------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-----------+------+-----+---------------------+-------+
| date | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| begin | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| end | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| date_mod | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| date_creation | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
+---------------+-----------+------+-----+---------------------+-------+show columns from glpi_users where `Default`= '2038-01-18 22:14:07';
+----------------------------+-----------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+-----------+------+-----+---------------------+-------+
| last_login | timestamp | YES | | 2038-01-18 22:14:07 | |
| date_mod | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| date_sync | timestamp | YES | | 2038-01-18 22:14:07 | |
| password_forget_token_date | timestamp | YES | | 2038-01-18 22:14:07 | |
| personal_token_date | timestamp | YES | | 2038-01-18 22:14:07 | |
| api_token_date | timestamp | YES | | 2038-01-18 22:14:07 | |
| cookie_token_date | timestamp | YES | | 2038-01-18 22:14:07 | |
| begin_date | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| end_date | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
| date_creation | timestamp | YES | MUL | 2038-01-18 22:14:07 | |
+----------------------------+-----------+------+-----+---------------------+-------+Is there any way to search the database all tables with this default value and change it to NULL? Instead of doing it table by table.
tomolimo
commented
4 years ago Hello @jcervantes-sipecom
There is a way to fix this: to write a PHP script to get all TIMESTAMP fields from the mysql DB, and to ALTER each field changing the default value to NULL instead of the current default value.
And more than that, the timezone migration script must be fixed to prevent such issue in future.
Thank you, Reards, Tomolimo
jcervantes-sipecom
commented
4 years ago Thank you so much @tomolimo,I was reviewing table by table of GLPI and its plugins with the graphical tool DBeaver, and I found some tables that have fields with this problem of the Default date, likewise I have verified that there are fields, few but there are, that cannot be NULL. So at the moment I am changed in the production base and the test base these fields, depending on my criteria, I put them NULL or else CURRENT_TIMESTAMP.
tomolimo
commented
4 years ago Hello @jcervantes-sipecom Could you give a list of what you have done? Thank you Regards, Tomolimo
jcervantes-sipecom
commented
4 years ago Sure let me prepare a complete list of what I've been doing.
I will list like this:
Give me this week to finish it.
github-actions[bot]
commented
3 years ago There has been no activity on this issue for some time and therefore it is considered stale and will be closed automatically in 10 days.
If this issue is related to a bug, please try to reproduce on latest release. If the problem persist, feel free to add a comment to revive this issue. If it is related to a new feature, please open a topic to discuss with community about this enhancement on suggestion website.
You may also consider taking a subscription to get professionnal support or contact GLPI editor team directly.
Describe the bug Hi, I don't know if this is an error in GLPI so I would ask for your help to solve it. The date '2038-01-18 22:14' is being inserted automatically in different parts of GLPI: in tickets when it's created by email receiver, tickettasks, begin date and end date in users when they are synced or imported with LDAP, etc.
I tried to look for some configuration in GLPI that is causing this behavior but I cannot find, I deactivated plugins and neither, in '/etc/php/7.4/apache2/php.ini' and '/etc/php/7.4/cli/php.ini 'I set date.timezone to my local timezone, restarted apache2 and the server but it keeps inserting that date.
Page(s) URL
To reproduce Steps to reproduce the behavior:
Tickets created by email receiver:
Tickettasks
Users synced/imported with LDAP
Expected behavior
Logs
Screenshots
-Users
Your GLPI setup (you can find it in Setup > General menu, System tab)