visite_date_min différente de visite_date_max

[lpojgc]

La modification a posteriori (après validation du formulaire) d'une date de visite, ne se répercute pas dans la colonne visite_date_max.

Exemple :

• je fais une visite que j'enregistre (au 17/03)
• je modifie la date de visite ensuite en mettant une date plus ancienne (11/03) - j'enregistre
• la date de visite max est conservée avec la date initiale (=17/03), la date_min est OK (=11/03).
  Visuellement dans le formulaire, je ne vois bien que la date corrigée.

Problème constaté sur un monitoring 1.2.6 sur une instance GN 2.16.4.
Je n'ai pas testé sur tous les modules que nous avons en prod sur notre instance, mais je trouve des dates incohérentes sur la plupart des modules.

[camillemonchicourt]

OK mince, faudrait corriger ça et potentiellement faire une migration de données pour celles dont la date_max est inférieure à la dte_min.

[lpojgc]

Je n'ai pas testé ce cas là, il doit être possible aussi.
Dans mon exemple c'est date_max > date_min alors qu'elles devraient être égales.
A anticiper pour la migration des données, il y a peut-être des protocoles pour lesquelles les dates min et max sont différentes. Je n'ai pas regardé le comportement attendu, mais pour le POPAmphibiens par exemple, on peut avoir un relevé sur 2 dates, @ahurabielle je ne sais pas si c'est géré dans le sous-module si l'heure de fin dépasse minuit.

[ahurabielle]

Le cas n'est pas géré pour POPA (ou POPR mais ne devrait pas se produire) si on dépasse minuit : on incite les personnes à ne saisir que sur une seule date.

[ahurabielle]

J'en profite aussi : sur le champ date, il peut y avoir un autre "bug"
Quand on passe par le calendrier, on ne peut pas saisir des dates dans le futur ou "incorrecte".

En revanche, si on tape "à la main" une date (comme au-dessus, j'ai indiqué 19/04/2026), le champ va bien être stocké en l'état.
Et potentiellement, quand le champ est mal formaté, cela peut faire "planter" monitorings : exemple d'une date de type 19/042/20226.