Lors d'une réservation avec périodicité, le dernier jour n'est pas immédiatement affiché réservé

[AndrewHobson]

C'est plus une demande de confirmation... puis en prime, il y a quelques questions au fil du texte !

Je voudrais juste m'assurer que le problème décrit ci-dessous était bien un bug et qu'il a été résolu ? Pas que ce soit un problème de paramétrage de mon environnement. Avez-vous le moyen de remonter dans les logs de vos modifications pour voir si un tel élément a été résolu ?

On a un comportement particulier, le matin avant 11h00, lorsqu'on fait une réservation avec périodicité sur plusieurs jours, le dernier jour réservé ne s'affiche pas immédiatement comme réservé (affichage avec la couleur). Mais dans les faits, la salle est bien réservée puisqu'on ne peut pas faire d'autre réservation sur cette salle pour ce jour.

Pour forcer l'affichage correct, on est obligé de modifier la réservation (sans rien changer), puis de valider et ensuite le dernier jour s’affiche avec les bons attributs.

J'ai testé avec la version de démo sur le site Internet de Devome (version 3.4.1d) et sur cette version je n'ai pas le bug. Tout fonctionne parfaitement bien.

Infos GRR Version de GRR : 3.4.0a Version PHP : 5.5.9 et mySql 5.5.62 Problème suite à une installation ou mise à jour : Non

Reproduire Étapes pour reproduire le comportement : Créer une réservation Cocher la case : Toute la journée Puis cliquer sur : Cliquez ici pour ouvrir les options de périodicité. Puis préciser une périodicité sur plusieurs jours consécutifs. Lorsqu'on valide, et qu'on revient sur l'affichage du calendrier, le dernier jour n'est pas affiché comme réservé

Comportement attendu La ressource doit immédiatement être affichée réservée

Contexte supplémentaire Il y a juste une chose, je me suis aperçu que mon serveur était sur Timezone (date_default_timezone_set) : Atlantic/Reykjavik Hors je suis dans la Timezone Europe/Zurich. C'est un élément que je peux corriger, mais qui va tout décaler les réservations déjà effectuées... Est-ce quîl y a un moyen de corriger cette timezone sans décaler les réservations existantes ?

J'ai une autre question... Comment puis-je faire la mise-à-jour de ma version 3.4.0 vers la version 3.4.1d ? Est-ce qu'il y a encore cette version 3.4.1d disponible quelque part au téléchargement ? On applique comment cet update, est-ce qu'il y a un expluicatif quelque part ? Des choses auxquelles il faut faire attention ?

Merci pour votre aide.

[ynaessens]

Bonjour, a priori ce bug a été corrigé. Pour la mise à jour, les instructions sont dans le fichier install.txt. Voici les différences entre les versions à jour : 3.4.3d compatible avec php 5.6+ 3.5.0 compatible avec php 5.6+ dont la base est codée en utf8 3.5.1 compatible avec php 5.6+, base en utf8 et cryptage amélioré des mots de passe 4.0.3 compatible avec php 7.2.5+ utilisant twig, base en utf8 et cryptage amélioré des mots de passe. Pour votre php, si la version 3.4.0 fonctionne, il est probable que la 3.4.3 aussi mais il faut tester. Cordialement YN

[AndrewHobson]

Bonjour, Merci pour ces précisions. Du coup, je me suis monté un petit serveur Ubuntu de test. J'ai installé la version 3.4.3c en test (sur github, j'ai pas trouvé la version 3.4.3d que vous mentionnez ?) Puis j'ai essayé d'importer le backup de ma base sql. Il me fait une erreur : Restauration à partir du ficher : grr_le_2023_04_28_a_15h17.sql (issu de ma version 3.4.0a) Unable to open file! Je suppose que c'est mon serveur de test qui est mal configuré. Où est-ce qu'il va uploader le fichier sql ? Je penses que c'est une question de droits en lecture/écriture sur des dossiers. Pouvez-vous m'aider sur cette question ? Merci

[ynaessens]

Bonjour, effectivement je me suis trompé d'indice, en 3.4.3 cela s'arrêté à c (pour l'instant ?). Je ne sais pas quels sont les détails de l'upload sur un système Ubuntu, pour ma part c'est Xampp qui télécharge dans son dossier /tmp. Donc a priori je dirais que c'est un problème de réglage de droits au niveau du serveur web de votre machine de test. Cordialement, YN

[AndrewHobson]

Bonjour, J'ai finalement réussi à importer la base de données. Le upload_max_filesize était trop petit. J'ai dû le booster un peu pour que ça passe.

J'ai eu les erreurs ci-dessous, n'étant pas un monstre expert avec mySQL, pouvez-vous me dire si je dois m'inquiéter de ces erreurs ou si on peut laisser couler ?

Résultat de la mise à jour Mise à jour jusqu'à la version 3.4.1 : Ok ! Mise à jour jusqu'à la version 3.4.2 : Erreur (non critique) sur la requête : ALTER TABLE grr_overload DROP PRIMARY KEY, ADD PRIMARY KEY (id_area,fieldname), ADD UNIQUE KEY id (id); (1062 : Duplicate entry '14-' for key 'PRIMARY') Mise à jour jusqu'à la version 3.4.3 : Erreur sur la requête : ALTER TABLE grr_log CHANGE REMOTE_ADDR REMOTE_ADDR VARCHAR(40) NOT NULL DEFAULT '' (1146 : Table 'grr.grr_log' doesn't exist)

Merci pour votre aide.

Andrew

[ynaessens]

Bonjour, pour la première erreur, comme indiqué c’est non critique. Je referai la manip’ afin de l’éliminer. Pour la seconde, c’est plus gênant. Il faudrait vérifier que la table _log existe bien. Quel est le préfixe de vos tables ? Si vous avez des clients en IP v6, la journalisation des connexions provoquera une erreur. Cordialement YN

[AndrewHobson]

Re-Bonjour,

Le préfixe de mes tables c'est grr Du coup la base de données se nomme grr et mes table sont prefixées de grr Et dans ma base de départ 3.4.0, je vois bien la table grr_log, mais effectivement, cette table n'est plus présente dans ma version convertie en 3.4.3 ?

J'ai un autre problème embêtant... Après l'update de la database par les scripts grr, je n'arrive plus me connecter à la base en utilisant mon compte Administrateur et mon mot de passe... C'est refusé. Je dois faire comment pour me sortir de cette gonfle ?

Puis c'est comme si il tourne en boucle, à chaque ouverture, il veut refaire la mise à jour des tables hors elles sont toutes passées de la v3.4.0 à la 3.4.3 et il n'y a plus d'update à faire.

Merci pour votre aide.

Andrew

[ynaessens]

Le problème avec la table grr_log, c’est qu’elle semble absente. Pouvez-vous vérifier avec phpmyadmin par exemple ? Ensuite, si elle est absente, lors du login, il y a une vérification qui va demander une mise à jour des tables… Enfin, le problème de connexion : soit la table grr_utilisateurs a été restaurée et alors il faut utiliser login:motDePasse de l’installation précédente, soit elle ne l’a pas été et alors il faut utiliser login:motDePasse que vous avez défini lors de l’installation. N’hésitez pas à revenir si vous restez coincé.

[AndrewHobson]

Bonjour,

J'ai refait l'import après avoir optimisé mes tables de départ. J'ai toujours des erreurs, mais celle sur la table grr_log est différente cette fois-ci :

Résultat de la mise à jour Mise à jour jusqu'à la version 3.4.1 : Ok ! Mise à jour jusqu'à la version 3.4.2 : Erreur (non critique) sur la requête : ALTER TABLE grr_overload DROP PRIMARY KEY, ADD PRIMARY KEY (id_area,fieldname), ADD UNIQUE KEY id (id); (1062 : Duplicate entry '14-' for key 'PRIMARY') Mise à jour jusqu'à la version 3.4.3 : Erreur sur la requête : ALTER TABLE grr_log CHANGE REMOTE_ADDR REMOTE_ADDR VARCHAR(40) NOT NULL DEFAULT '' (1067 : Invalid default value for 'START')

Pouvez-vous m'aider ?

Merci et meilleures salutations.

Andrew

[ynaessens]

Bonjour, on progresse :-) L’erreur dans grr_log est sur la valeur par défaut des dates. Au lieu des valeurs nulles, il faut mettre le 1er janvier 1970 à 00:00:00, ou toute autre date valide. Je pensais que c’était corrigé, je vérifie dès que possible. Cordialement YN

[AndrewHobson]

Re-Bonjour,

Pour la 1ère erreur non critique, quel est l'utilité de la table grr_overload ? Car j'ai effectivement 2 enregistrements dans cette table, il y a deux fois la valeur 14 dans le champ id_area. Puis-je simplement supprimer un des deux avant la migration ? Mais lequel choisir ;-)

Merci pour votre retour.

Andrew

[ynaessens]

C’est le couple (id_area, fieldname) qui est unique. Que constatez-vous ? Sur l’utilité de la table, elle fait la liaison entre les domaines et les champs additionnels.

[AndrewHobson]

Alors j'ai ceci : 2 x 14 comme id_area et 2 x du vide pour fieldname

[ynaessens]

D’où l’erreur. Je pense que vous pouvez tout supprimer.

[ynaessens]

Bonjour, je reviens sur l'erreur relative aux datetime : la valeur par défaut a été modifiée sur GRR 3.2 en février 2017... vous avez une base "historique" ;-) L'essentiel est que vous ayez pu migrer sans perte de données. Vous confirmez ? Cordialement, YN

[AndrewHobson]

Bonjour,

Alors effectivement, on utilise Grr depuis très très longtemps ! La dernière migration que j'avais réalisée c'était en août 2018 pour passer à la version 3.4.0a...

Avec tes précisions, j'ai réussi à migrer ma base de la version 3.4.0a vers la 3.4.3c sans erreur SQL. Ceci dans mon environnement de test.

Pour le problème sur la table grr_log, j'ai procédé comme suit : J'ai du taper cette commande : SET GLOBAL sql_mode = ''; Sinon j'avais une erreur 1067. Puis j'ai modifié les deux champs : grr_log => START et j'ai mis la valeur par défaut (Tel que défini) 1970-01-01 00:00:00 grr_log => END et j'ai mis la valeur par défaut (Tel que défini) 1970-01-01 00:00:00

Puis les scripts de mise-à-jour de la database ont fonctionné.

Donc si tu me dis que ma manière de procéder est OK, je vais migrer ma base en production ?

Pour la suite des migrations vers la 3.5.1, il me faut mettre à jour mon serveur Ubuntu. Mais c'est dans le pipeline ! Ce sera pour un prochain épisode.

Avec mes meilleures salutations. Andrew

[ynaessens]

Tout a l'air bien. Je te suggère quand même de passer en revue les pages de votre GRR historique sur ton serveur de test pour confirmer que la migration est passée sans encombre. Et pour la mise en production, je ferais une sauvegarde du serveur de test en 3.4.3 pour la restaurer directement sur le nouveau serveur. Bonne continuation !