Development #51330
préremplissage dynamique d'un champ sur la même page
0%
Description
Maintenant que le préremplissage est rejoué sur les champs s'ils n'ont pas été modifiés, on peut étendre ça pour fonctionner sur la même page.
champ 1 [....] champ 2 [....], prérempli form_var_champ1
et ce qui est écrit dans le champ 1 serait reproduit dans le champ 2, tant que celui-ci n'a pas été manuellement mis à une valeur différente.
Faire attention au cas où le préremplissage se fait sur une valeur du profil de l'usager, ce qui peut désormais être modifié en cours de route lors de la saisie backoffice.
(dev mutualisé https://publik.tracim.fr/ui/workspaces/1/contents/html-document/894)
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a environ 3 ans
- Fichier 0001-forms-recompute-prefills-on-live-changes-51330.patch 0001-forms-recompute-prefills-on-live-changes-51330.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
En fait un patch fait de quantité de petites choses :
- on inclut désormais la classe widget-prefilled de manière systématique pour les champs configurés avec du préremplissage; avant on ne le faisait pas quand le préremplissage donnait une chaine vide; on fait ça parce que c'est sur base de la classe widget-prefilled qu'on va mettre à jour le champ ou pas.
- ça fait que côté js quand un champ est modifié on retire la classe widget-prefilled.
- et dans l'appel à l'url /live pour obtenir les résultats, on passe la liste des champs préremplis (ex: ?prefilled_1=on&prefilled_4=on&...)
- il y a une valeur particulière quand l'usager associé à une demande est modifié (ce qui arrive quand on est en saisie backoffice et qu'on choisit un usager en barre latérale); on passe dans ce cas ?modified_field_id=user
- il y a la situation particulière de blocs de champs où on clique sur le bouton pour ajouter une ligne, dans la suite il y a court-circuitage du préremplissage et donc les champs qui étaient déjà là n'ont plus la classe widget-prefilled; ça m'ennuyait vraiment d'avoir à tout recalculer après un clic sur "ajouter" (après avoir déjà fait #51314 pour recalculer l'aspect "champ verrouillé"); c'est pour contourner cette partie du problème que j'ai fait #51369 pour que la partie "ajouter" soit gérée ajax et sans incidence sur les autres champs.
Mis à jour par Thomas Noël il y a environ 3 ans
Sur ce moment :
elif get_request().form.get('modified_field_id') == 'user': # user selection in sidebar formdata.user_id = get_request().form.get('user_id')
J'ai l'impression que ça pourrait permettre, en bidouillant le user_id envoyé au live, de voir les infos pré-remplies de n'importe quel user dans le résultat du live...? Il faudrait peut-être vérifier qu'on est bien en backoffice ?
Mis à jour par Frédéric Péters il y a environ 3 ans
Mis à jour par Thomas Noël il y a environ 3 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit b091599f369fc57367df9776cd48ad4dee2867c1 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Mon Feb 22 15:50:20 2021 +0100 forms: recompute prefills on live changes (#51330)
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
Mis à jour par Pierre Cros il y a environ 3 ans
Je m'attendais à c e que ça fonctionne ici et c'est pas le cas :
https://demarches-montoulouse.cutm-publik-preprod.nfrance.com/backoffice/submission/allo-toulouse-signalements/ (EDIT : URL modifiée)
Peut-être parce que c'est un bloc de champ qui est employé :
https://demarches-montoulouse.cutm-publik-preprod.nfrance.com/backoffice/forms/blocks/3/
Mis à jour par Frédéric Péters il y a environ 3 ans
Tu pointes deux fois l'URL vers la définition du bloc, je pense que tu voulais pointer l'endroit où constater l'affaire en premier.
Mis à jour par Frédéric Péters il y a environ 3 ans
ça fonctionne ici
Étant donc une situation de saisie backoffice où l'usager est choisi en barre latérale et du préremplissage à partir de champs du profil configuré sur des champs d'un bloc de la démache.
(mais là en local, même sans l'affaire de bloc j'ai l'impression qu'un bug tardif s'est introduit).
Mis à jour par Frédéric Péters il y a environ 3 ans
- Lié à Bug #51686: préremplissage dynamique en saisie backoffice avec juste du préremplissage usager ajouté
Mis à jour par Frédéric Péters il y a environ 3 ans
- Lié à Development #51688: préremplissage dynamique vers des champs de blocs ajouté
Mis à jour par Pierre Cros il y a environ 3 ans
J'ai rétabli la bonne URL dans mon commentaire initial.
Mis à jour par Brice Mallet il y a environ 3 ans
J'avais fait un formulaire de test : https://demarches-mkuntz.test.entrouvert.org/brice/test-pre-remplissage-puis-reinitialisation/ (BO : https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/163/), je m'attendais à ce que le pré-remplissage fonctionne dans tous les cas sur la même page (sur la page 1) or ce n'est pas le cas, est-ce un problème de configuration, de ce que devait faire le développement ou un bug ?
Mis à jour par Frédéric Péters il y a environ 3 ans
Tu peux dire ce que tu attendais plus précisément que "dans tous les cas" ?
Mis à jour par Brice Mallet il y a environ 3 ans
Tu peux dire ce que tu attendais plus précisément que "dans tous les cas" ?
Désolé, j'avais loupé ta réponse.
"dans tous les cas" : que ce qui fonctionne en pré-remplissage sur une page suivante, fonctionne maintenant en pré-remplissage sur la même page.
- le déclencheur de la mise à jour est https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/163/fields/4/
- cela déclenche bien la mise à jour
- du champ commentaire (https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/163/fields/3/)
- et du champ texte sur la même page (https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/163/fields/5/)
- mais pas
- de la liste (https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/163/fields/12/)
- et du sous-titre (https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/163/fields/15/)
qui, eux, ne sont mis à jour / pré-remplis que sur la page suivante ainsi que sur la première page, mais seulement au retour sur celle-ci
Mis à jour par Frédéric Péters il y a environ 3 ans
de la liste
C'était hors scope précisé dans tracim, "Pré-remplissage dynamique des champs Texte (court et long)", mais je vais faire un ticket.
et du sous-titre
Il n'y a pas de notion de préremplissage sur les sous-titres.
Mis à jour par Renaud Boitouzet il y a environ 3 ans
Bonjour, je m'immisce dans vos échanges, pardon si ce n'est pas approprié !
Je ne sais pas si c'est pertinent/possible de changer ça, mais en reprenant l'exemple du formulaire de test https://demarches-mkuntz.test.entrouvert.org/brice/test-pre-remplissage-puis-reinitialisation/ si on passe en page 2 sans avoir modifié manuellement le champ texte prérempli dynamiquement, puis qu'on revient en page 1, le pré-remplissage dynamique ne fonctionne plus.
Le comportement n'est donc pas le même selon que l'usager arrive sur la page pour la première fois ou qu'il y revienne.
J'ai trouvé plusieurs tickets connexes mais qui datent d'avant la mise en place du préremplissage dynamique : #43369, # 45348.
Mis à jour par Brice Mallet il y a environ 3 ans
C'était hors scope précisé dans tracim, "Pré-remplissage dynamique des champs Texte (court et long)", mais je vais faire un ticket.
La demande initiale émanait de Toulouse qui demandait explicitement uniquement pour les champs textes ; mais comme ce développement est la suite de "Pré-remplissage de champs Texte et Liste : réinitialisation après changement de condition", j'ai sur-interprété que cela s'appliquerait aussi sur les listes.
Nota : le ticket de Fred = #51897
Il n'y a pas de notion de préremplissage sur les sous-titres.
En effet pas "pré-remplissage", "mise à jour automatique" serait plus juste ; il n'empêche que comme de plus en plus de champs de saisie et de champs de mise en forme (commentaire, titre, sous-titre) sont mis à jour depuis un déclencheur, je trouve qu'il serait bien que le comportement soit identiques pour tous les champs (i.e. mise à jour en direct même si le déclencheur est sur la page même page), je vais faire un courriel à ce sujet
forms: recompute prefills on live changes (#51330)