Feuille de temps disparue après update en 18.0

ConsoliX · Septembre 20, 2023, 6:40

Second problème avec mon passage à la v18

Je n’ai jamais eu de soucis lors des updates précédents et me voici confronté à un second soucis…

Après l’update, les feuilles de temps n’existaient plus, la page était complètement vide…

Du coup, j’ai restauré la table llx_project_task_timesheet (merci les backups), mais maintenant j’ai bien récupéré les encodages précédents, mais quand on fait une mise à jour ou un ajout, les modifications ne sont pas faites sur la DB.
C’est comme si les feuilles de temps étaient en read-only… Et dans le dolibarr.log, je vois bien les commandes SQL pour les updates…

Quelqu’un aurait une idée ?

J’en suis à me demander si je ne remettrais pas mon backup de la v17

Merci d’avance pour votre aide.

clad63 · Septembre 21, 2023, 5:34

Bonjour,

vous parlez du module externe Feuille de temps ou du temps consommé du module Projet/taches?

FHenry · Septembre 21, 2023, 7:06

je vous confirme que ceci n’est pas une table standard Dolibarr, il faut donc voir avec le développeur/editeur du module

en v17 la saisie des temps passés sur une tache c’est llx_projet_task_time
en v18 c’est devenu llx_element_time ( en prévision d’une évolution qui permettrais de pouvoir saisir du temp sur autre chose que des taches d’un projet)

ConsoliX · Septembre 22, 2023, 9:14

Je parle bien de la feuille de temps standard liée aux tâches/projets.

Ce n’est pas un module additionnel mais bien celui qui est présent par défaut dans Dolibarr.

ConsoliX · Septembre 22, 2023, 9:16

Oui, erreur de ma part, il s’agit bien de la table llx_projet_task_time qui fait partie du module standard de dolibarr.

Par contre, lors de la migration en v18, apparemment il ne l’a pas convertie en llx_element_time et il l’a simplement supprimée.

Il suffit de la renommer pour que cela fonctionne à nouveau ou il y a eu des modifications sur la structure de la table également ?

FHenry · Septembre 22, 2023, 11:17

Bonjour,

La structure de la table est différente mais c’est bien un renommage et adaptation

Dans le fichier

dolibarr/htdocs/install/mysql/migration/17.0.0-18.0.0.sql

Si vous êtes bien avec Mysql pas PostgreSQL il y a ça (qui aurais du faire le travail)


ALTER TABLE llx_projet_task_time RENAME TO llx_element_time;

SET sql_mode = 'ALLOW_INVALID_DATES';
update llx_element_time set task_date = NULL where DATE(STR_TO_DATE(task_date, '%Y-%m-%d')) IS NULL;
SET sql_mode = 'NO_ZERO_DATE';
update llx_element_time set task_date = NULL where DATE(STR_TO_DATE(task_date, '%Y-%m-%d')) IS NULL;

ALTER TABLE llx_element_time CHANGE COLUMN fk_task fk_element integer NOT NULL;
ALTER TABLE llx_element_time CHANGE COLUMN task_date element_date date;
ALTER TABLE llx_element_time CHANGE COLUMN task_datehour element_datehour datetime;
ALTER TABLE llx_element_time CHANGE COLUMN task_date_withhour element_date_withhour integer;
ALTER TABLE llx_element_time CHANGE COLUMN task_duration element_duration double;
ALTER TABLE llx_element_time ADD COLUMN elementtype varchar(32) NOT NULL DEFAULT 'task' AFTER fk_element;

DROP INDEX idx_projet_task_time_task on llx_element_time;
DROP INDEX idx_projet_task_time_date on llx_element_time;
DROP INDEX idx_projet_task_time_datehour on llx_element_time;

ALTER TABLE llx_element_time ADD INDEX idx_element_time_task (fk_element);
ALTER TABLE llx_element_time ADD INDEX idx_element_time_date (element_date);
ALTER TABLE llx_element_time ADD INDEX idx_element_time_datehour (element_datehour);

ALTER TABLE llx_element_time ADD COLUMN ref_ext varchar(32);

Vous pouvez tenter de restauré la table llx_projet_task_time uniquement et de lancer ces instruction SQL pas à pas et voir le résultat

Mais cela veux dire qu’il y a peut être eu d’autre opération qui ne sont pas bien passé lors de la migration, vous n’avez pas eu d’erreur ?

ConsoliX · Septembre 22, 2023, 1:08

Ben apparemment cette table existe aussi et pourtant il m’est impossible d’encoder quoi que ce soit de nouveau.

Je n’ai pas eu de message d’erreur pendant l’update, est-ce qu’il existe un log de la mise à jour quelque part ?

FHenry · Septembre 23, 2023, 6:50

Est dans les log Dolibarr Mode DEBUG, il y a le mot « roolback » au moment de la modification ou la saisie d’un temps passé ?

Schesco · Septembre 25, 2023, 3:35

Nous sommes dans le même cas après une mise à jour en 18.0 :

La table llx_projet_task_time a été remplacée par llx_element_time occasionnant la déconnexion de tous nos reportings.

Avez-vous trouvé une solution @ConsoliX ? Est-il possible de recréer l’ancienne table de manière automatisée dans Dolibarr ?

Goudro · Octobre 5, 2023, 3:15

Bonjour,

nous vivons le même problème actuellement.

Avez-vous trouvé une solution?

Merci beaucoup du retour!

Schesco · Octobre 5, 2023, 9:08

Bonjour,

La table llx_projet_task_time a été renommée en llx_element_time. Mais le contenu est le même, il y a juste une colonne en plus qui indique le type d’élément. « Task » pour les tâches.

Les logs de mise à jour précisent :

ALTER TABLE llx_projet_task_time RENAME TO llx_element_time;
ALTER TABLE llx_element_time CHANGE COLUMN fk_task fk_element integer NOT NULL;
ALTER TABLE llx_element_time CHANGE COLUMN task_date element_date date;
ALTER TABLE llx_element_time CHANGE COLUMN task_datehour element_datehour datetime;
ALTER TABLE llx_element_time CHANGE COLUMN task_date_withhour element_date_withhour integer;
ALTER TABLE llx_element_time CHANGE COLUMN task_duration element_duration double;
ALTER TABLE llx_element_time ADD COLUMN elementtype varchar(32) NOT NULL DEFAULT ‹ task › AFTER fk_element;

Dans notre cas précis nous avons modifié les tables sources de nos reportings. Les tâches et leurs temps sont dans la nouvelle table llx_element_time.

ConsoliX · Octobre 24, 2023, 9:25

Bonjour à tous,
Désolé pour la réponse tardive…
Oui j’ai pu résoudre le problème, mais d’une manière pas très catholique
En fait j’ai réinstallé une version 17 avec une restauration de ma DB, cela a refonctionné comme avant.
Par contre, en appliquant la 18, j’ai eu de nouveau le même soucis.
Alors sur base des informations dans les mails précédents j’ai restauré le contenu de la table llx_projet_task_time dans llx_element_time en faisant un mapping des colonnes tel qu’expliqué par Schesco. Et là… Miracle, cela a refonctionné
Bref c’était un peu scabreux, mais on a de nouveau une solution qui est fonctionnelle.

cmaconception · Janvier 26, 2024, 7:49

Merci pour cette info, je viens de m’apercevoir que ma table avait également disparue suite à la migration V18 mais mon problème est résolu.

bva · Février 29, 2024, 5:29

Bonjour,

j’ai le message d’erreur suivant après une migration de 16.0.3 vers 18.0.5 :

Dolibarr a détecté une erreur technique.
Ces informations peuvent être utiles à des fins de diagnostic (vous pouvez définir l'option $dolibarr_main_prod sur '1' pour masquer les informations sensibles):
Date: 20240229182311
Dolibarr: 18.0.5 - https://www.dolibarr.org
Niveau de fonctionnalités: 0
PHP: 7.4.13
Server: Apache
OS: Linux svm 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0

Url sollicitée: /xxx/htdocs/timesheet/TimesheetReportProject.php?projectSelected=259
Referer: https://xxx.xxx.xxx.xxx/vvv/htdocs/projet/card.php?id=259&save_lastsearch_values=1
Gestionnaire de menu: eldy_menu.php

Modules/Applications: user, reception, documentgeneration, dav, bookmark, accounting, agenda, banque, commande, ecm, expensereport, facture, fournisseur, margin, printing, resource, service, societe, ticket, website, timesheet, propal, supplier_proposal, projet, tax, contrat, debugbar, subtotal, product, skype, expedition, categorie, fckeditor, multicurrency, mailing, workflow, import, export, ficheinter
Type gestionnaire de base de données: mysqli
Requête dernier accès en base en erreur: SELECT tsk.fk_projet as projectid, ptt.fk_user as userid, tsk.rowid as taskid, (ptt.invoice_id > 0 or ptt.invoice_line_id>0) AS invoiced, MAX(ptt.rowid) as id, GROUP_CONCAT(ptt.note SEPARATOR '. ') as note, MAX(tske.invoiceable) as invoicable, DATE(ptt.task_datehour) AS task_date, SUM(ptt.task_duration) as duration FROM llx_projet_task_time as ptt JOIN llx_projet_task as tsk ON tsk.rowid = fk_task LEFT JOIN llx_projet_task_extrafields as tske ON tske.fk_object = fk_task WHERE tsk.fk_projet IN ('259') AND DATE(task_datehour) >= '2024-01-01 18:23:11' AND DATE(task_datehour) <= '2024-01-31 18:23:11' AND (ptt.task_duration > 0 or LENGTH(ptt.note)>0) GROUP BY ptt.fk_user, tsk.fk_projet, tsk.rowid, DATE(ptt.task_datehour), (ptt.invoice_id > 0 or ptt.invoice_line_id>0) ORDER BY tsk.fk_projet,ptt.fk_user, tsk.rowid, DATE(ptt.task_datehour) ASC
Code retour dernier accès en base en erreur: DB_ERROR_NOSUCHTABLE
Information sur le dernier accès en base en erreur: Table 'vvv.llx_projet_task_time' doesn't exist

J’ai appliqué les requêtes SQL de @FHenry. Elles passent bien sauf les DROP des index.
Il est normal que llx_projet_task_time n’existe plus puisque c’est désormais

llx_element_time

Merci bien pour votre aide.
B