Development #24844
Auto-soumission en cas de page déjà remplie
0%
Description
- à Nanterre: problème d'accès concurrent à session_var_rsuid par plusieurs formulaire (un agent commence une démarche sur une fiche puis sur une autre, mélange de session_var_rsuid, fail...)
- au CD05 pour le champ de sélection de la commune en première page: on peut utiliser soit ce champ soit session_var_commune ça complexifie toutes les conditions et les templats ensuite (on doit systématiquement faire
form_var_commune or session_var_commune)
Je remarque une première chose: comme quixote mélange le body du POST et la query string, on a déjà du pré-remplissage automatique sur présence du nom d'un champ, exemple:
Ici f1 est le champ Nom, et en arrivant sur la première page il est bien pré-rempli.
Ce que je propose ce serait de pouvoir préciser pour une page (ici la première) que si elle est pré-rempli on peut immédiatement passé à la suivante (donc nouveau booléen sur PageField, "autosubmit_if_filled"). Pour simplifier un peu et ne pas avoir à utiliser f1, f2, etc... je ferai en sorte que ça se pré-remplisse aussi sur le nom de la variable utilisée dans la query string (donc ici pour l'exemple en mettant ?nom=coin).
Sur Nanterre on ajouterait à tous les formulaires une première page de choix du RSU_ID, comme ce serait pré-rempli on ne la verrait jamais, mais en cas d'erreur on aurait pas un formulaire tout cassé, ensuite dans le reste du formulaire on pourrait référencer form_var_rsuid sans que ça se mélange avec un autre formulaire en cours de remplissage.
Sur CD05 la page existe déjà, il n'y aurait qu'à activer la nouvelle option.
Historique
Mis à jour par Frédéric Péters il y a presque 6 ans
Actuellement pas à l'aise, peut-être parce que la proposition me semble mélanger deux choses, une nouvelle forme de prise en compte de la query string et le passage transparent/automatique sur les pages dont tous les champs seraient préremplis. (et peut-être aussi parce que niveau code j'ai peur de ce que ça demanderait, et peut-être aussi parce que niveau utilisation je crains toujours les abus).
Mis à jour par Benjamin Dauvergne il y a presque 6 ans
Oui oui il y a deux tickets d'implémentation derrière, si j'avais un tracker 'Idée' je le mettrai dedans.
Il faut effectivement implémenter deux choses assez indépendante- un pré-remplissage via la querystring (ça me parait assez simple et rentrer facilement dans le code actuel, on peut même prévoir 3 types:
- pré-remplissage simple,
- pré-remplissage toujours vérifié (le champ devient locké dans tous les cas),
- pré-remplissage sur URL signé (on peut pré-remplir avec une donnée qui devient vérifiée mais uniquement si on a une URL signée).
Pour l'instant je n'ai besoin que du cas le plus simple, pour pouvoir pré-remplir plus loin dans le formulaire il y a nécessité de conserver un extrait de la query string dans les données magictoken comme fait avec future_tracking_code (je reconnais que ça continue dans une voie que tu souhaites voir disparaître mais le boulot ne sera pas plus compliqué que de se passer de magictoken pour future_tracking_code je pense).
- l'auto-soumission si tous les champs valides (pas forcément s'ils sont pré-remplis)
C'est effectivement plus compliqué parce qu'il faut le faire au premier passage sur une page mais voir ce que ça implique au niveau navigation. Une autre voixe serait de gérer ça les conditions de page mais en faisant en sorte que le pré-remplissage soit pris en compte même sans submit explicite (donc quand on saute des pages via .is_visible() au seint de .get_start_page() ou .previous_page() ou le partie gérant le saut à la page suivante).
Je suis d'accord qu'une remise à plat est plus importante qu'une complexification dans l'immédiat.
Mis à jour par Frédéric Péters il y a presque 2 ans
- Statut changé de Nouveau à Fermé
- Planning mis à Non
Pour supprimer l'utilisation des session_var_* et le problème de non utilisation des champs qui en découle:
La direction prise a été les champs "données calculées".