search

JeromeDevome / GRR

GRR Officiel - Copyright Team DEVOME
https://grr.devome.com
GNU General Public License v2.0
84 stars 53 forks source link

Proposition de correction d'un bug d'affichage dans la version 3.5.1e #386

Open Philippe34 opened 2 months ago

Philippe34 commented 2 months ago

Bonjour,

J'ai rencontré un bug d'affichage d'une ressource affichée par semaine

Une réservation pour le 8 octobre 2024 était affichée incorrectement dans le planning du 1 octobre. Elle s'affichait aussi correctement dans le planning du 8 octobre. Remarquez la 2è semaine ( 07 octobre - 11 octobre) s'affichant incorrectement sans ressources

image

image

J'ai corrigé ce problème en modifiant la ligne 134 de week.php

// BUG $week_end = mktime($eveningends, $eveningends_minutes, 0, $month_week, $day_week + 6, $year_week);
$week_end = mktime($eveningends, $eveningends_minutes, 0, $month_week, $day_week + 1, $year_week);

La réservation ne s'affiche plus incorrectement le 01 octobre et l'affichage est beaucoup plus propre image

Et la réservation du 8 octobre est bien affichée image

SI vous acceptiez de publier le correctif, cela pourrait être utile à ceux qui doivent encore rester comme moi en version 3.5.1

Cordialement

ynaessens commented 2 months ago

Bonjour, je ne reproduis pas le bug que vous avez décrit. Cependant, la page comportait des erreurs d'arrondi implicite que php 8.2 rejette. J'ai donc modifié le code en conséquence cf. https://github.com/JeromeDevome/GRR/commit/2f5faa20d7f1b6254cfc89b3beeb8f6ed209a871 Cordialement, YN

Philippe34 commented 2 months ago

Bonjour @ynaessens Je vous remercie pour vos correctifs, je vais tester dès que possible. Désolé d'avoir oublié de vous indiquer la version de PHP. Notre GRR tourne sous PHP 8.1.29 Cordialement

Philippe34 commented 2 months ago

Je viens d'ajouter le correctif week.php et cela ne change pas la nature du défaut d'affichage que je constate. Toutefois, ce correctif a solutionné l'issue "#359 Warnings et deprecated s'affichent lorsqu'on sélectionne une ressource".

En fait, je me demande si ce défaut ne provient pas du fait qu'il s'agit d'une migration de GRR 1.9.7e (PHP 5.3) vers 3.5.1 (PHP 8.1) sur une nouvelle machine (avec récupération de la base de données) et que quelque chose n'aurait pas été proprement upgradée. Y aurait-t-il un utilitaire de vérification de la base de données que je pourrai lancer ?

Merci.

ynaessens commented 2 months ago

Bonjour, à la réflexion, je soupçonne un décalage dans les heures système entre les deux serveurs. Le bug décrit se produit-il avec toutes les réservations, ou uniquement les nouvelles, ou les anciennes ? Cordialement, YN

Philippe34 commented 2 months ago

Bonjour, Nous avons 4 domaines dans notre GRR : salles, véhicules, matériels, divers. Et ce décalage ne se produit que pour le domaine salles et non les autres domaines. A noter que c'est essentiellement le domaine salles qui est utilisé pour les réservations. Le problème d'affichage ne se produit que pour week.php et non pour week_all.php

Je montre une vue d'une ressource du domaine véhicules. Je n'ai pas noté de pb et il n'y a aucune décalage :

image

Si je reprends la vue d'une ressource du domaine salles, on voit ce décalage dans les jours et aussi, une répétition des heures (8h - 00h, 00h - 24h, 00h -24h, .... Je peux constater que ce bug se produit pour toutes les réservations du domaine salles, les anciennes et les nouvelles et uniquement lorsqu'on affiche une ressource (une salle). J'ai vérifié que les heures systèmes étaient les mêmes sur les 2 serveurs, mais cela semble lié à un problème d'heures comme vous le suggérez

image

La modification que j'avais proposée ne résoud que partiellement le problème pour le domaine salles : le décalage pour les salles disparait, mais pas la répétition des heures.

Malheureusement, il en induit de nouveaux sur les autres domaines, comme véhicules. Sur cette image du domaine véhicules, les dates s'arrêtent au mardi

image

Je suis perplexe. Auriez-vous des suggestions ? Encore merci

ynaessens commented 2 months ago

Je suis également perplexe. Il faudrait pouvoir tester votre base de données, mais il semble que Github n'a pas de messagerie privée. Je vous invite à rejoindre le groupe Discord. Cordialement, YN

Philippe34 commented 2 months ago

Merci @ynaessens pour votre invitation à Discord. Cordialement

Philippe34 commented 1 month ago

Un retour pour vous signaler que je suis parvenu à régler la majorité des bugs et rendre l'application utilisable.

Il y avait ce problème que je n'avais pas encore signalé, mais lorsqu'on faisait apparaitre toutes les réservations en choisissant un jour du calendrier, cela mettait plusieurs dizaines de secondes à se charger car la page affichait les ressources sur une semaine, au lieu de seulement celles du jour. Correctif qui a marché: day.php: ligne 122 

//$pm7 = mktime($eveningends, $eveningends_minutes, 0, $month, $day, $year);
$pm7 = $am7 + 43200 ;

Et pour corriger le problème de l'affichage des semaines: week.php: ligne 137

//$week_end = mktime($eveningends, $eveningends_minutes, 0, $month_week, $day_week + 6, $year_week);
$week_end = $week_start + 86400 * 7;

Je n'ai pas réussi à corriger le problème de l'affichage des heures qui se répètent sur une semaine lorsqu'on choisit une ressource et qui fait appel à week.php

En conclusion, je ne crois pas que le problème vienne de la base de données puisque les réservations s'affichent sans erreur, mais plutôt dans le calcul du temps avec mktime(). Comme ces bugs n'apparaissaient pas sur les domaines avec peu de réservation, mais seulement avec le domaine des salles (plus de 40000 réservations), cela est peut-être lié à la volumétrie des réservations.

Cordialement

ynaessens commented 1 month ago

Bonjour, votre message est énigmatique : quels sont les si nombreux bugs que vous avez eu à régler ? Pour ce qui est de la taille de votre base de données, je doute un peu que ce soit la source des soucis, lorsque j'étais au lycée, nous avions l'emploi du temps reporté dans GRR, ce qui faisait de l'ordre de 2000 créneaux sur 36 semaines, et ça fonctionnait. Pour ce qui est des correctifs que vous proposez :

Enfin, merci pour votre remarque relative à mktime(), certains calculs semblent pouvoir être évités. Je regarde cela de plus près dès que possible. Cordialement, YN

Philippe34 commented 1 month ago

Désolé si mes messages sont confus. Les bugs sont ceux que j'ai tenté de décrire dans ce fil.

Je vais illustrer avec le problème du calendrier avec des réservations très longues à s'afficher car s'affichant sur plusieurs jours au lieu de seulement le jour que j'ai sélectionné en cliquant sur la date.

Avec le day.php d'origine, la requête SQL est:

SELECT start_time, end_time, grr_entry.id, name, beneficiaire, grr_room.room_name,type, statut_entry, grr_entry.description, grr_entry.option_reservation, grr_room.delais_option_reservation, grr_entry.moderate, beneficiaire_ext, clef, grr_entry.courrier, grr_entry.overload_desc,grr_entry.room_id, grr_entry.create_by, grr_entry.nbparticipantmax
WHERE grr_room.area_id = 11  AND start_time < 1730223000 AND end_time > 1729749600

Si je traduis en langage humain, cela correspond à une recherche sur l'intervalle: start_time < mardi 29 octobre 2024 18:30:00 [GMT+01:00] AND end_time > jeudi 24 octobre 2024 08:00:00 [GMT+02:00]

L'intervalle est sur 5 jours, ce qui explique les lenteurs et le bug d'affichage Cela correspond à la requête: $sql .= " AND start_time < ".($pm7+$resolution)." AND end_time > ".$am7."

Avec la modification que j'ai apportée: $pm7 = $am7 + 43200 ; j'obtiens ceci:

SELECT start_time, end_time, grr_entry.id, name, beneficiaire, grr_room.room_name,type, statut_entry, grr_entry.description, grr_entry.option_reservation, grr_room.delais_option_reservation, grr_entry.moderate, beneficiaire_ext, clef, grr_entry.courrier, grr_entry.overload_desc,grr_entry.room_id, grr_entry.create_by, grr_entry.nbparticipantmax
WHERE grr_room.area_id = 11  AND start_time < 1729276200 AND end_time > 1729231200

Soit: start_time < vendredi 18 octobre 2024 20:30:00 [GMT+02:00] AND end_time > vendredi 18 octobre 2024 08:00:00 [GMT+02:00]

J'ai bien une recherche sur la journée et l'affichage est quasi instantané.

Je ne m'explique pas comme vous pourquoi ajouter 43 200 (12h) fait quand même apparaitre la journée en entier.

Une piste ? : l'environnement de travail de mon serveur PHP 8.1.29 est sous Linux (Rocky Linux 8.10). Peut-il y avoir des différences avec d'autres environnements, comme PHP sous Windows ?

ynaessens commented 1 month ago

Bonjour, merci pour votre réponse très détaillée. Ce que je ne comprends pas, c'est que dans la page day.php, pour demain 18 octobre, j'ai la requête : SELECT start_time, end_time, grr_entry.id, name, beneficiaire, grr_room.room_name,type, statut_entry, grr_entry.description, grr_entry.option_reservation, grr_room.delais_option_reservation, grr_entry.moderate, beneficiaire_ext, clef, grr_entry.courrier, grr_entry.overload_desc,grr_entry.room_id, grr_entry.create_by, grr_entry.nbparticipantmax FROM (grr_entry JOIN grr_room ON grr_entry.room_id=grr_room.id) WHERE grr_room.area_id = 2 AND start_time < 1729276200 AND end_time > 1729231200 ORDER BY start_time c'est-à-dire start_time < 18/10/2024 @ 20:30:00 et end_time > 18/10/2024 @ 08:00:00 ce qui valide le calcul de $am7 et $pm7.

Si vos journées font effectivement 12 heures, l'intervalle que vous avez choisi est convenable, et ça marche ! Je ne pense pas que votre installation soit en cause dans ce dysfonctionnement, à moins que mktime() soit défaillante ?

Philippe34 commented 1 month ago

Bonjour, Je voudrais vous remercier pour votre intérêt aux problèmes que j'ai rencontrés et les échanges que nous avons eu pour tenter de comprendre.

Je vous souhaite une excellente journée.