En V13.0.1, il apparait un méchant bug sur l’agenda pour les événements sur une journée
Dolibarr affiche le jour précédent au champs datep ( qui est à la date du jour à l’heure 00:00:00) pour tous les évènements planifiés sur une journée.
Exemple, datep=2021-06-01 00:00:00 de llx_actioncomm => dolibarr affiche l’événement le 31/05
Jusqu’à datep=2021-06-01 00:59:00 => dolibarr affiche l’événement le 31/05
A partir de 1H du matin soit datep=2021-06-01 01:00:00 => dolibarr affiche correctement l’événement le 01/06
MAIS si l’on modifie l’évènement ( ou l’on peut pas modifier l’heure pour un évènement sur une journée), Dolibarr remet dans mon exemple le champs datep à 2021-06-01 00:00:00
=> rebelote, dolibarr affiche l’événement le 31/05
En continuant à modifier le même événement sans changer la date, celui avance d’un jour à chaque fois.
Ce bug empêche totalement l’utilisation de l’agenda.
EDIT: le probléme ne se produit qu’à partir du 28 mars et le 31 octobre, soit pendant l’horaire d’été.
Je reproduit en 13.0.1 : vérifie qu’il n’y ai pas d’issue déclarée sur github
si c’est le cas -> relance
si ça n’est pas le cas créé en une
Je pense que ça n’est pas un « bug » de dolibarr à proprement parler mais un problème induit par la prise en compte de paramétrages d’apache. (voir même un bug induit par une correction d’un autre bug: ça me rappelle un truc, mais je ne sais plus quoi)
Je regardé coté timezone et je me suis assuré que toutes les time zones sont à Europe/Paris au niveau O/S, mysql et dolibarr ( même en forçant le paramètre MAIN_SERVER_TZ à "Europe/Paris, auto)
Par contre, dans la pages « info Dolibarr » , j’ai toujours heure d’été à NON dans la ligne:
Fuseau horaire PHP (serveur) +1 (+3600) Europe/Paris Heure d’été: Non (Oui en été)
j’ai jeté un oeuil, ça doit venir de la définition de $datep et $datef qui fait appel
dol_mktime() qui fait appel à dol_print_date() dans \comm\action\card.php
et là, il y a un timezone du user qui rentre en jeu.
Mais lui, je ne comprends pas d’où il vient.
Ce bug se produit effectivement à minima dans
/comm/action/index.php
/comm/action/card.php
La version 13 introduit l’utilisation de l’option tzuser ou tzuserrel dans l’appel à dol_print_date et cela engendre ce bug en heure d’été pour la timezone Europe/Paris. cette option récupère apparemment la timezone du browser mais il doit y avoir un dysfonctionnement.
Pour corriger le bug temporairement j’ai modifié toutes les valeurs tzuser et tzuserrel par la variable « tzserver » dans tous les fichiers php du répertoire /comm/action pour forcer la localisation à la timezone du server ( qui est bien dans mon test à Europe/Paris pour mon serveur)
Vous trouverez dans le tar ci-joint le répertoire /htdocs/comm en V1301 avec cette correction
Je confirme ce pb également sur ma version 13.0.1. En revanche, à l’affichage, le pb n’est visible que sur la vue Hebdo mais pas sur la vue Mensuel… !?
J’ai tenté ton fix sur ma pré-prod mais ça ne fonctionne pas.
En espérant une correction rapide car c’est en effet très bloquant.
@Sickboy79 bien vu, mais bizarre : moi j’ai la même chose sur les deux.
mais sur la vue en liste : tu as quoi ?
moi j’ai date de début+heure = date de fin+heure
il ne s’agirait donc peut être pas d’un pb de création/update de donnée, mais d’un pb d’affichage ?
[EDIT] : j’ai vérifié en bdd, les dates/heures de début son bonnes en base de données.
Ce sont donc les affichages qui provoquent l’écart, pas leur enregistrement. (en tout cas dans mon cas, car ce sont des différences de timezone qui sont gérées dans le code)
le probléme est bien aussi en update des données, le champs datep de la table llx_actioncomm est mal mis à jour systématiquement avec une heure de moins à chaque changement ( Modification de l’event ou drag and drop dans l’interface mois du calendrier).
j’ai bien moi le probléme en vue hebdo comme en vu mois.
Bizarre que mon fix ne fonctionne pas, je viens de le tester sur la 1302, et il fonctionne aussi.
Se mettre dans le repertoire htdocs:
Renommer le répertoire comm
tar xvfz comm_1301_fix.tar.gz
Il est possible que ma solution marche uniquement après avoir forcé la TZ dans Dolibarr ( Menu Divers):
MAIN_SERVER_TZ à « Europe/Paris,auto »
@Sickboy79
si tu veux t’y aventurer: il faut écraser tes fichier avec les nouveaux (en ayant sauvegardé les tiens avant)
mais ça n’est pas un fix: c’est un bidouille (que j’imagine bien fonctionner dans certains cas) qui remplace les appels à des fonctions qui posent problème dans certains cas.
non, tu renommes le répertoire htdocs/comm et tu décompresses directement dans /htdocs
le tar compressé contient le repertoire « comm », donc il va le recréer
Effectivement c’est une bidouille en attendant le fix. Mais j’ai pas pu faire mieux en attendant.
@henosis c’est pas un reproche hein le « bidouille »
c’est juste que je suis modérateur sur le forum et que je n’ai pas envie de voir pleins de gens débarquer en disant « ouainnnn j’ai appliqué ça, ma base marche plusssss comment revenir en arrrrièrreee ??? » (tu imagines bien je pense ^^)
donc en attendant : « bidouilles » testées et maitrisées → oui
mais la règle générale : attendre le correctif sur github
je vais rentrer dans le php sinon on va être obligé de revenir à la 12.
