Evolution #1881: La Recherche avancée sur les champs dynamiques de type date ne fonctionne pas en Français - Galette - Galette bugs & features

Rapports personnalisés

All, by project
Open bugs, by project
Open tasks, by project
Whishes

Actions

Copier le lien

Evolution #1881

ouvert

La Recherche avancée sur les champs dynamiques de type date ne fonctionne pas en Français

Ajouté par Alain Paris il y a 4 mois. Mis à jour il y a 13 jours.

Statut:

Résolu

Priorité:

Normal

Assigné à:

Johan Cwiklinski

Catégorie:

Fields management

Version cible:

1.2.0

Début:

20/10/2024

Echéance:

% réalisé:

100%

Temps estimé:

Vote:

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

base de données galette_dynamic_fields.jpg (21,1 ko) base de données galette_dynamic_fields.jpg

Alain Paris, 20/10/2024 16:42

Historique
Notes
Changements
Révisions associées

Actions

Copier le lien

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.

Actions

Copier le lien

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...

Actions

Copier le lien

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).

Actions

Copier le lien

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.4~~ supprimé

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.

Actions

Copier le lien

Mis à jour par Johan Cwiklinski il y a environ un mois

Version cible mis à 1.2.0

Actions

Copier le lien

Mis à jour par Johan Cwiklinski il y a environ un mois

Statut changé de Nouveau à Résolu
% réalisé changé de 0 à 100

Actions

Copier le lien

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).

Actions

Copier le lien

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).

Actions

Copier le lien