Bug #41784
Perte de la valeur d'un champ date en édition d'une demande en backoffice
0%
Description
Lors d'une édition de demande en backoffice, j'ai un champ date qui ne reprend pas sa valeur.
Sur la capture d'écran : le champ "date de la demande".
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a environ 4 ans
C'est l'input type=date, c'est la même histoire que #41674, sauf que ça va être pénible de satisfaire dans ce cas-ci à la fois les anciens et les nouveaux navigateurs. (on doit fournir une valeur yyyy-mm-dd, qui va être pourrie pour les anciens navigateurs). (il faut quand même chercher si autre chose est possible, ou finir en bidouille avec du js).
Mis à jour par Stéphane Laget il y a environ 4 ans
Le pré-remplissage ne fonctionne plus non plus (constaté dans un formulaire de WF)
Mis à jour par Marie Kuntz -> retour le 13 mai il y a environ 4 ans
Est-ce qu'on peut rollback le champ date ou c'est déjà passé en prod ? ça va faire perdre la valeur saisie lors de l'édition des démarches pour la Réunion, c'est très ennuyeux.
Mis à jour par Frédéric Péters il y a environ 4 ans
Ce n'est pas en production; c'était ma crainte au moment de #41674 mais plus à #41674#note-5.
On notera aussi mon message Publik du 23 avril qui contenait : "de manière visible pour tout le monde avec l'utilisation d'un champ date natif (#11109)".
Mis à jour par Frédéric Péters il y a environ 4 ans
- Fichier 0001-forms-always-use-yyyy-mm-dd-for-date-input-values-41.patch 0001-forms-always-use-yyyy-mm-dd-for-date-input-values-41.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Ce n'est pas tellement possible de tester ça correctement parce que ça vient de l'interprétation par les navigateurs, idéalement webtest devrait faire le même genre de conversion et ça permettrait de détecter ces erreurs.
Mis à jour par Nicolas Roche il y a environ 4 ans
- Statut changé de Solution proposée à Solution validée
Chez moi ça corrige, mais le navigateur ne passe pas dans le javascript.
Je ne constate pas de régression vis-à-vis de #41666.
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
le navigateur ne passe pas dans le javascript
C'est normal, s'il gère les champs date. C'est pour ça que j'ajoute $date_input.attr('type', 'text') au patch, pour simplement pouvoir mettre en commentaire la première ligne "prefer native date widget" et pouvoir ainsi tester le fallback local.
commit 76270a6fea268e4129a010b8d39dab7d8852ba61
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Thu Apr 16 17:58:16 2020 +0200
forms: always use yyyy-mm-dd for date input values (#41784)
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
forms: always use yyyy-mm-dd for date input values (#41784)