Nouvelle version candidate 3.5.0-RC2 - Erreur sur la requête utf8mb4

Bonjour,
je vous propose une nouvelle version de GRR. github.com/JeromeDevome/GRR/releases/tag/v3.5.0RC2
Elle corrige quelques erreurs de code et de vocabulaire, et ajoute deux fonctionnalités :

• affichage du bénéficiaire dans le tableau des réservations à modérer
• possibilité de sélectionner ou exclure les jours de vacances scolaires ou fériés dans les réservations périodiques

Sauf rapport de bugs, cette version passera en stable d'ici à trois semaines.
Merci à tous pour vos suggestions et retours d'expérience.
Cordialement,
YN

Yan,
merci de votre célérité pour les résa périodiques. Je m'en vais l'essayer de suite...

Bonjour,
Merci pour toutes ces améliorations. Je viens d'installer cette nouvelle version en test mais j'ai ce message qui apparait à l'installation: "Passage de grr_log en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Erreur sur la requête : ALTER TABLE grr_log CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci (1067 : Invalid default value for 'START')"
Mais cette erreur n'affecte pas apparement le fonctionnement de GRR. Par prudence, je ne la déploie pas encore.
La configuration du serveur est la suivante :
Système d'exploitation : Linux serveur.
Version PHP : 7.4.30
Base de donnée : mysql 10.3.35-MariaDB-cll-lve
Une correction à faire pour résoudre cette erreur ?
Cordialement,
Denis

Bonjour,
quand vous dites, à l'installation, je dois comprendre que c'est lors de la conversion d'une ancienne base vers le format utf8mb4, n'est-ce-pas ?
D'anciennes bases avaient une valeur nulle par défaut pour le champ START, ce qui est désormais refusé.
Pouvez-vous confirmer mon analyse ?
Cordialement,
YN

Bonjour,
Oui je confirme. C'est en passant de la version 3.4.3b vers la 3.5.0-RC2 tout en gardant l'ancienne base de données que j'ai eu cette erreur.
Cela peut poser un problème ce message pour le bon fonctionnement de GRR ? ou je n'en tiens pas compte ?
Cordialement,
Denis

Bonjour,
en partant d'une base créée depuis GRR 3.4.3b, cela ne devrait pas se produire. Votre base n'a-t-elle pas été héritée d'une version plus ancienne ?
J'ai inclus un correctif dans le script de mise à jour qui devrait éliminer cette erreur.
Je publie la version stable 3.5.0 sous peu.
Cordialement,
YN

Bonjour,
Ma base d'origine provient d'une version beaucoup plus ancienne que 3.4.3b (je peux en archives remonter jusqu'à 2013).
J'ai fait la migration vers la version stable 3.5.0 et j'ai toujours ce message et même un autre qui est apparu qui est :
Erreur sur requête : ALTER TABLE 'grr_log' CHANGE 'START' 'START' DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00'; (1067 : Invalid default value for 'END')
Erreur sur requête : ALTER TABLE 'grr_log' CHANGE 'END' 'END' DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00'; (1067 : Invalid default value for 'START')
Du à l'ancienne base je suppose ? Apparement pas de dysfonctionnement de GRR. Si vous pensez que cela n'a pas de conséquence sur le bon fonctionnement de GRR, j'ignore ces erreurs et je reste sur cette nouvelle installation.
Merci encore pour cet travail,
Cordialement,
Denis

Bonjour,
c'est bizarre, la requête a été récupérée de phpmyadmin. Ma version de MariaDB est 10.4.22-MariaDB.
Il faudrait rechercher dans l'historique de Github, mais le rejet des dates nulles commence à dater.
Quelle structure a la table grr_log de votre base ?
Comme je vous le disais précédemment, a priori cette erreur ne nuit pas au fonctionnement de GRR puisque les données entrées par le logiciel sont correctes.
Cordialement,
YN

Bonjour,
La structure de la table est la suivante (fichier-joint). Je remarque que "datetime" a comme valeur "0000-00-00 00:00:00". Cela viendrait de là ?
Et c'est normal que cette table a en interclassement "latin1_swedish_ci" alors que toutes les autres tables ont comme valeur la valeur utf8mb4_unicode_ci" ?
Cordialement,
Denis

Bonjour,
ce que vous avez n'est pas normal. La mise à jour devrait avoir converti les champs de type varchar en utf8mb4_unicode_ci et changé la valeur par défaut de START et END à '1970-01-01 00:00:00'.
Un problème de droits sur la table grr_log ?
Cordialement,
YN
P.S.: par phpmyadmin, vous pouvez changer les valeurs par défaut ainsi que le type des varchar