Evolution #1881
ouvert
La Recherche avancée sur les champs dynamiques de type date ne fonctionne pas en Français
100%
Description
Les dates des champs dynamiques sont enregistrés dans galette_dynamic_fields dans le format de date de la langue d'enregistrement.
Les recherches effectuées en langue anglaise fonctionnent seulement sur les dates qui ont le format yyyy-mm-dd
Les recherches effectuées en langue française ne fonctionnent pas , pas de résultat quelque soit le format de la date.
extrait de la requête :
en Fr:
FROM `galette_dynamic_fields` AS `df` WHERE `df`.`field_form` = 'adh' AND `df`.`field_id` = '19') AS `df19` ON `a`.`id_adh` = `df19`.`item_id` WHERE a.activite_adh=true
AND STR_TO_DATE(df19.val, '%d/%m/%Y') < STR_TO_DATE('2000-01-21', '%d/%m/%Y') ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0
en En:
FROM `galette_dynamic_fields` AS `df` WHERE `df`.`field_form` = 'adh' AND `df`.`field_id` = '19') AS `df19` ON `a`.`id_adh` = `df19`.`item_id` WHERE a.activite_adh=true
AND STR_TO_DATE(df19.val, '%Y-%m-%d') < STR_TO_DATE('2000-01-21', '%Y-%m-%d') ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0
Fichiers
Mis à jour par Johan Cwiklinski il y a 4 mois
- Priorité changé de Normal à Bas
Le problème, c'est que le champ dynamique ne stocke pas la langue dans laquelle la langue a été enregistrée ; il est donc impossible d'effectuer une recherche correcte (l'affichage aussi est incorrect, mais c'est une autre histoire).
Cela ne peut pas être corrigé, les données existantes seront forcément incorrectes - je n'ai pas de solution à proposer.
Mis à jour par Alain Paris il y a 4 mois
Le calcul des dates des champs du cœurs sont plus simples:
WHERE a.activite_adh=true AND a.ddn_adh> '1981-01-01' ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0
Je pense qu'il faudrait que les données date des champs dynamiques de "galette_dynamic_fields" soient en version yyyy-mm-dd , comme toutes les autres tables de Galette.
C'est pour cela que je pensais "évolution" au départ.
La recherche libre est expérimentale OK , mais si l'on recherche une date (champs dynamiques) dans contributions, toutes les langues ne donnent pas de résultat (ici c'est l'inverse OK en Fr It De.., HS en En). Après si l'association n'est pas internationale et que les adhérents n'utilisent qu'une seule langue...
Mis à jour par Johan Cwiklinski il y a 4 mois
Alain Paris a écrit (#note-2):
Le calcul des dates des champs du cœurs sont plus simples:
WHERE a.activite_adh=true AND a.ddn_adh> '1981-01-01' ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0
Oui, mais ce sont des champs de type date, là où les dates dyanmiques sont juste du texte. Ça rend les choses plus compliquées, mais que le format soit "quantique" n'aide pas ^^
Je pense qu'il faudrait que les données date des champs dynamiques de "galette_dynamic_fields" soient en version yyyy-mm-dd , comme toutes les autres tables de Galette.
C'est pour cela que je pensais "évolution" au départ.La recherche libre est expérimentale OK , mais si l'on recherche une date (champs dynamiques) dans contributions, toutes les langues ne donnent pas de résultat (ici c'est l'inverse OK en Fr It De.., HS en En). Après si l'association n'est pas internationale et que les adhérents n'utilisent qu'une seule langue...
Je ne sais pas du tout comment les langues sont utilisées, ça dépend de toutes façons du compte de l'adhérent connecté... Et ça peut changer \o/
Je laisse en "bug" pour le moment, je requalifierai au besoin (ça ne change pas grand chose pour le moment).
Mis à jour par Johan Cwiklinski il y a 4 mois
- Tracker changé de Anomalie à Evolution
- Catégorie mis à Fields management
- Assigné à mis à Johan Cwiklinski
- Priorité changé de Bas à Normal
- Version utilisée
1.1.4supprimé
Résumé de la discussion Discord sur le sujet :
Il apparaît que la seule manière de vraiment corriger ça c'est de stocker les dates au format Y-m-d et des les afficher en utilisant la locale courante (comme toutes les autres dates de Galette en somme).
Pour les données existantes, un script dans les outils d'administration à lancer explicitement par l'utilisateur pourra être fourni, les données seront ainsi préservées par la migration standard.
Mis à jour par Johan Cwiklinski il y a 30 jours
- Statut changé de Nouveau à Résolu
- % réalisé changé de 0 à 100
Mis à jour par Alain Paris il y a 13 jours
Bonjour,
Modification de l'enregistrement de la date sous la forme Y-m-d :
La recherche avancée concernant les champs dynamiques de type date est effectuée en utilisant le format de la langue de la page de l'utilisateur.
En attendant une harmonisation complète des champs DATE en Y-m-d (désormais le nouveau format d'enregistrement unique de la V1.2).
Il faudrait peut être modifier les requêtes en incluant la recherche avec 2 formats: la langue utilisée + format Y-m-d
Avec la nightly Galette v1.2-git-27d354281f (2025-02-08 15:13:04 GMT+0100) la recherche ne donne de résultat qu'en En (sur les derniers enregistrements (version Y-m-d)) par exemple.
Je ne me rappelles plus si la recherche fonctionnait dans d'autres langues que l'En.
Concernant la recherche sur une date particulière dans les contributions , ici aussi il faudrait que la requête soit dans la langue utilisée ET en Y-m-d .
Bien sur il y aura toujours problème tant que le format en base ne sera pas le même que celui de l'utilisateur ou Y-m-d (fiche enregistrée dans un format (avant 1.2), recherche dans un autre etc..).
De toute façon la solution sera d'avoir les données au même format (futur outil administrateur).
Mis à jour par Johan Cwiklinski il y a 13 jours
- Statut changé de Résolu à In Progress
Il faudra que je revoie tout ça à tête reposée ; je n'ai plus tout en tête.
Actuellement, toutes les dates sont stockées au format Y-m-d.
Côté interface, elles sont affichées et saisies dans la langue de l'utilisateur courant.
À la saisie, le sélecteur de date corrige en live si l'on entre à la main un autre format. Quand bien même il serait possible de contourner le sélecteur pour entrer un format inconnu, cela déclencherait une erreur côté PHP. Dans le code sous-jacent, il est historiquement possible d'utiliser le format localisé ou pas : 09/02/2025 et 2025-02-09 fonctionneront tous deux. Ce bidouillage servait à l'origine à contourner des problèmes résolus depuis, pour le quidam, il doit saisir la date dans sa langue.
Les dates qui ne sont pas au bon format en base (dans le cœur de Galette, ça ne concerne normalement que les champs dynamiques de type date) ne seront pas prises en compte. Le format en base doit être le bon (ce sera le travail de l'outil de redressement qui n'est certes pas disponible, mais il le sera).
Il reste possible que les requêtes utilisées pour les champs dynamiques de type date soient incorrectes (pour le coup, il faut que je vérifie comment on cherche sur les "autres" dates et comment on fait pour les dates dynamiques).
Mis à jour par Johan Cwiklinski il y a 13 jours
Johan Cwiklinski a écrit (#note-8):
[...]
Il reste possible que les requêtes utilisées pour les champs dynamiques de type date soient incorrectes
Alors, il semble que j'ai effectivement complètement oublié de changer ça ! Un correctif arrive.
Mis à jour par Johan Cwiklinski il y a 13 jours
- Statut changé de In Progress à Résolu
Appliqué par commit 9baf0217de3931cef5c3ea83208636fe3abf0b73.