Evolution #1881
ouvert
La Recherche avancée sur les champs dynamiques de type date ne fonctionne pas en Français
0%
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 environ un 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 environ un 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 environ un 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 environ un 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.