Re: [Galette-devel] Gestion des groupes affichage

[alain Paris <alain.paris77@xxxxxxx>]

Bonjour,

J'ai fais des tests ce n'est pas une utilisation normale ,pour les recherches enregistrées celles-ci étant liées à la personne connectée, la probabilité qu'il change de langue est minime.

Je ne sais pas si c'est le fait de mes tests  mais du coup affichage de la page journaux (history) l’abréviation du jour est en  anglais (Thu 25/11/2021 - 11:45) perso cela ne me dérange pas.

Composer dans le fichier platform-check impose PHP 7.4  ce qui me gène, notre association est chez un hébergement mutualisé qui ne propose pas au delà de PHP 7.3.

(il semble que modifier le fichier platform-check.php  permette d'utiliser galette en PHP 7.3 je ne sais pas si cela peut jouer sur le comportement de celle-ci).

Bonne journée

A.Paris

Le 29/11/2021 à 12:02, Johan Cwiklinski a écrit :

> Salut,
>
> Le 28/11/2021 à 18:37, alain Paris a écrit :
> > OK cela corrige ce que j'avais constaté.
> >
> > Recherches enregistrées:
> >
> > Pour les dates dans les recherches enregistrées, les critères
> > enregistrés sont dans la langue  de l'enregistrement
> > (01.01.1980,1980-01-01,01/01/1980....) et forcement si l'on change de
> > langue (c'est pour chercher la petite bête) la résultat n'est pas le bon.
> >
> > Les dates n’étant pas au format attribué la recherche ne tiens pas
> > compte de ce critère.
> >
> > Les dates ont déjà posé des problèmes dans galette...
> >
> > Base de donnée de galette les dates enregistrées dans les tables sont
> > elle toujours de type yyyy-mm-dd comme chez moi ? .Diffèrent-elle si
> > l'on a installé galette en anglais par exemple ?
> >
> > Est il possible d'enregistrer toute les dates et critères divers selon
> > le même format "base de donnée", et que le format d'affichage lui se
> > modifie en dernier suivant la sélection de la langue ?
> >
> > Peut être gros travail ,a voir pour évolution future (Galette 10).
> >       
> Normalement, c'est déjà le cas ; enfin, plus ou moins. Le code devrait
> être davantage factorisé pour être sûrs que tous les cas soient pris en
> compte de la même manière - mais les dates ne doivent pas être stockées
> sous leur forme localisée en base. En plus pour la recherche
> enregistrée, tout est stocké en une fois dans un champ "texte", c'est un
> cas particulier.
>
> Ce que j'ai pu constater, c'est que la date des recherches enregistrées
> en stockée au format localisé ("29/11/2021" pour aujourd'hui).
> Normalement, on enregistre toujours "2021-11-29" et on compose à
> l'affichage. Après, les erreurs des traductions, c'est encore autre
> chose (c'est pas moi qui traduit :D).
>
> Ce que j'ai aussi constaté, c'est que de ré-exécuter la recherche
> enregistrée produit un requête avec les dates au bon format.
> J'ai testé avec pas mal de champs de la recherche avancée en une seule
> fois, le seul problème potentiel que j'aie vu concernerait la recherche
> sur un champ date dynamique.
>
> Du coup, mes résultats semblent bons (testés avec une date de naissance
> par ex.).
>
> La version 0.9.6 est prête, s'il n'y a plus de problèmes majeurs,
> j'aimerai autant qu'elle puisse sortir maintenant ; il y a plusieurs
> correctifs de sécurité ; et j'aimerai embrayer sur le sujet du
> changement d'interface graphique (y'a encore « un peu de boulot » pour
> ça :D).
>
> À noter: j'ai très récemment supprimé le champ adresse2_adh (après
> l'avoir concaténé, à l'adresse_adh) ; il y a tout ce qu'il faut dans le
> script de migration ;)
>
> ++
>