Produits Entr'ouvert » Publik

J'ai pas compris. Un champs que l'usager ne peut pas modifier, il restera vide... quel intérêt ?

Thomas Noël a écrit :

J'ai pas compris. Un champs que l'usager ne peut pas modifier, il restera vide... quel intérêt ?

Ça suppose en plus que le champ est pré-rempli.

Ça suppose plein de choses, il y a une série de situations, avec des réponses différentes, qui se trouvent derrière ce ticket. C'est l'objet du "lister tous les cas d'usage connus", sans quoi le ticket est creux, oui.

En y allant avec mon biais technique, il y a des questions d'affichage, pour éviter le hack de créer un champ liste avec un seul élément.

Mais il n'y a pas juste "lecture seule", il y a aussi "caché", la pratique existe d'utiliser un champ de formulaire prérempli par une expression Python pour gagner une valeur calculée, utilisable plus tard. Avec du hack pour taper le champ en "display: none", ça donne par exemple #18911. Ou l'utilisation de session_var_ qui cassent lors de saisies concurrentes de demandes parce que l'info n'est pas attachée à une demande.

Frédéric Péters a écrit :

C'est l'objet du "lister tous les cas d'usage connus", sans quoi le ticket est creux, oui.
(...) Ou l'utilisation de session_var_ qui cassent lors de saisies concurrentes de demandes parce que l'info n'est pas attachée à une demande.

Exemple à Villeurbanne :
Traitemenent des demandes d'emplois.
Les postes et leur descriptifs sont exposés sur le site de la Ville, le bouton "postuler" renvoie vers Publik avec plusieurs variables de session, dont le libellé du poste (mais également d'autres infos comme la date de réponse minimum et le service en charge du recrutement)
On a besoin du nom du poste dans le formulaire.
Le pré-remplissage d'un champ form_var_poste avec la session_var_ permet de disposer du nom du poste dans une variable de formulaire, et est enregistrée tout de suite. Mais pour cela, il faut soit cacher le champ au candidat, soit lui exposer ce champ en l'empêchant de le modifier (read-only)
Si le candidat ne va pas au bout et décide de garder sa candidature dans un brouillon, il peut reprendre sa demande plus tard, avec le nom du poste qui sera enregistré dans form_var_poste.
Sans le pre-remplissage de cette variable, s'il reprend son brouillon, la variable de session est perdue, et le candidat répond à une offre d'emploi sans que l'on sache à quel poste il répond !
Aujourd'hui cela se contourne en cachant le champ au candidat avec la classe "hidden" mais ce n'est pas satisfaisant.

Saisi d'un point sur un champ carte.

Ce point permet de pré-remplir des champs adresse (numéro, voie, code postal ville) et ces champs devraient ne pas être modifiables (en particulier dans les cas ou le point de carto entraine des automatismes dans le circuit de traitement ensuite => découpage par quartier, responsable de traitement différent suivant la zone de déclaration...)

Nanterre / tous les projets qui font des formulaires BO liés à un identifiant externe (dossier, fiches, que sais-je)

Pouvoir persister un paramètre passé en session et le référencer pendant le remplissage du formulaire (appels à la variable webservice notamment) et plus tard dans le workflow, permettre d'ouvrir plusieurs fois le même formulaire avec un paramètre différent (les session_var s'écrasent si même paramètre utilisé dans deux onglets avec des valeurs différentes).

(rajout de Thomas : en l’occurrence ça serait ici des champs read-only + remplis + cachés, genre "form_var_rsu_id" où on stocke "session_var_rsu_id" -- pour l'instant on le fait dans l'étape 1 du workflow dans une donnée de traitement, avec le risque que les session_var aient été modifiées par un autre formulaire dans un autre onglet entre temps)

• une pré-demande (avec instruction sur la faisabilité et l'opportunité)
• un demande complète (= dossier technique en lien avec la pré-demande)
  La 2eme demande est automatiquement remplie par les éléments de la 1ère demande. On peut créer cette 2ème demande avec l'action de re-soumission, ou un webservice interne pour créer une 2ème demande, ou l'utilisation d'un JDS ou en restant sur la 1ère demande et en jouant avec des pages conditionnelles pilotées par une donnée de traitement.
  Mais dans tous les cas, cela permet de pré-remplir des champs qui restent modifiables par l'usager, alors que l'on ne voudrait pas, car ces éléments ont été instruits et validés par l'agent lors de la pre-demande.
  Si ces champs ne sont pas affichés dans le formulaire à l'usager (parce que cachés dans une page conditionnelle), actuellement on les perd lors de la soumission du formulaire par l'usager.
  L'option "read-only" sur les champs réglerait le pb.

• un champ avec une valeur dérivée d'un attribut vérifié du profil (profil vérifié par FranceConnect), il est souhaité que ce champs soit en lecture seule
  • pour certains champs il est possible au niveau de authentic2-auth-fc de générer au niveau du profil une donnée vérifiée (par exemple civilité) et donc l'implémentation actuelle des champs en lecture seule suffirait,
  • pour d'autres plus liés au formulaire lui même ce sera difficile (exemple, un champs "né en France", c'est directement calculable via l'identité pivot FranceConnect, ça n'a pas vocation à faire partie du profil, même en attribut caché à l'utilisateur, surtout que ce n'est pas facilement configurable par la collectivité et donc nécessite notre intervention).

Cas d'usage qui ne nécessite pas de développement : Lille qui voulait un champ en lecture seule et à qui j'ai dit "champ commentaire", ils sont contents : #29974

Avec les données de traitement qui arrivent bientôt dans les formulaires, je vois pas trop ce dont on aurait besoin en plus en fait.

Nouveau cas d'usage : pouvoir effectuer un calcul complexe/intermédiaire qui serait exploité plus loin dans le formulaire ou utilisé plusieurs fois, sans forcément vouloir les afficher avec un champ verrouillé.
Très pratique pour les calculs de prestation avec trouze mille champs à prendre en compte.

Cas d'usage (#48937).

Pouvoir faire une condition d'affichage d'un champs de formulaire page avec des requêtes du type :

cards|objects:"quota"|filter_by:"identifiant_evt"|filter_value:identifiant|first|get:"nombre" <= cards|objects:"quota"|filter_by:"identifiant_evt"|filter_value:identifiant|first|get:"quota" 

où la valeur identifiant est calculée depuis une valeur d'un champ précédent.

• Le calcul peut se faire dans un {% with %} mais le champs condition d'affichage d'un champs de formulaire ne prend pas {% with %}.
• Préremplir un champs verrouillé précédent sur le formulaire pour définir cette chaîne pose le problème d'afficher cette valeur.

La possibilité de valeurs calculées dans le formulaire pourrait permettre de calculer l'identifiant sans l'afficher.

• besoin de remplir un champ par :
  • query string passée en url
  • session_var
  • calcul basé sur les valeurs des champs précédents
  • calcul basé sur les filtres
• besoin que la valeur de ce champ soit réutilisable plus loin dans le formulaire ou le workflow
• besoin que ce champ soit caché à l'usager

Mik, dans #27429#21, je ne suis pas certaine de bien cerner ton besoin. J'ai l'impression qu'il y a plusieurs demandes en une.

Non c'est ok, ta liste à point réponds à mon besoin :

• L'usager sélectionne un événement défini dans form_var_evenement sur une première page.
• Sur la page suivante se trouve un champs form_var_identifiant_evt qui contient en préremplissage form_var_evenement_slug|split:"-"|slice:":-1"|join:"-"
• Ce champs "technique" n'est pas affiché à l'usager grâce à ce développement (je l'affiche aujourd'hui verrouillé).
• La valeur de ce champs est utilisé sur cette même page dans la condition d'affichage d'un champs : cards|objects:"quota"|filter_by:"identifiant_evt"|filter_value:form_var_identifiant_evt|first|get:"nombre" <= cards|objects:"quota"|filter_by:"identifiant_evt"|filter_value:form_var_identifiant_evt|first|get:"quota"

Impec alors.
Est-ce que le chiffrage qui avait été initalement avancé tient toujours avec ce périmètre mis à jour ?

Je ne saisissais pas,

besoin de remplir un champ par :

query string passée en url
session_var
calcul basé sur les valeurs des champs précédents
calcul basé sur les filtres

parce que tout ça est déjà possible.

Mais c'est parce qu'en fait j'ai été perdu par le "un champ", que j'associais à quelque chose du formulaire.

Dans le pad associé, on parle de "Données de traitement intra-formulaire", et ok ça dit peut-être trop peu de choses mais je serais plus à l'aise pour étendre la description à partir de là (pas ce soir), plutôt que parler de "champs".

Oui, j'hésitais à parler de donnée de traitement mais c'est exactement ça, dans ma tête. Il faut pouvoir, comme dans les wf, leur assigner une valeur à un moment précis dans le formulaire, donc dans ma tête ça ressemble à """un champ de type donnée de traitement""" que tu mets entre deux champs classiques.
J'y ai réfléchi et je ne sais pas s'il est nécessaire de les définir en amont (comme dans les wf), avec un type de champ (par exemple, un type liste qui permettrait d'avoir ensuite des stats dessus, personne n'a abordé le cas, je réfléchis un peu loin)

Nickel. De mon côté j'étais à pencher pour ne pas passer par la mécanique des champs ici, et être explicitement disponible uniquement lors de la saisie.

On aurait dans la définition d'une page, un paramétrage "variables éphémères" (je prends ce nom pour me distinguer totalement du reste mais il faudra trouver autre chose),

  Variables éphémères
   [ identifiant_evt..... ]   [ {{ form_var_evenement_slug|split:"-"|slice:":-1"|join:"-" }}....... ]
   [ .....................]   [ ................................................................... ]
   <ajouter>

et ça donne sur la page, disponible pour les conditions etc. des champs, un {{ form_ephemere_identifiant_edt }}.

En évolution, il pourrait y avoir une option pré/post, pour déterminer si la variable est créée à l'affichage de la page ou au "submit" de celle-ci (pour par exemple produire une variable qui serait exploitée dans une condition de sortie.

Je notais "éphémères", je préciserais dispos jusqu'au moment de la validation de la demande, et là y compris l'exécution initiale du workflow (même si techniquement ça va sans doute compliquer un peu la vie), pour ainsi facilement permettre de transférer ces variables dans des données de traitement pérennes.

Frédéric Péters a écrit :

En évolution, il pourrait y avoir une option pré/post, pour déterminer si la variable est créée à l'affichage de la page ou au "submit" de celle-ci (pour par exemple produire une variable qui serait exploitée dans une condition de sortie.

En attendant l'évolution, par défaut ce serait pré ou post ?

Je pense actuellement pencher pour "pré" mais ça se discute tellement que je me dis qu'il faut intégrer les deux dès le début.

Ma préférence pour le "pré" c'est que ça permettrait de mettre dans une variable stable un {{request.GET.whatever}} sur la première page, pour plus loin ou ailleurs ne jamais avoir à faire référence à request.GET.

Dans l'autre sens, sur le "post", c'est utile ça permettrait des calculs un peu complexes pour bloquer le passage à la page suivante.

Je note que bien qu'éphémères il faudra que ces valeurs restent stockées dans les brouillons (et donc pas juste en session s'il y avait cette idée derrière). Perso je ne pensais pas à cette notion d'éphémère, je la trouve dommage, ça va lier fortement formulaire et workflow, ce qui n'est jamais agréable. Je pensais juste appeler ça "Données calculées" et que ça finisse dans des form_var_whatever classiques (avec un type qui pourrait être list ou bool ou autre grâce à l'évaluation complexe).

Je ne vois pas comment avoir une variable form_ephemere_plop définie quelque part dans le formulaire, versus une variable form_var_pas_ephemere_plop définir quelque part dans le formulaire, va lier plus ou moins fortement formulaire et workflow.

À l'inverse, je pense même que ça lierait moins de cantonner ces variables au moment du formulaire. (et pour défendre ce point de vue je serais même à retirer ma proposition qu'était la mise à disposition à l'exécution initiale des variables).

Les avoir au-delà de la saisie ça va amener à avoir des workflows qui dépendent directement de celles-ci et il se trouvera bien un moment où il faudra rejouer une action de workflow sur une demande réalisée à un moment où la variable n'était pas définie, et ça va du coup appeler à la création d'une action similaire à "données de traitement", pour modifier ces variables, etc. sans fin.

C'est pas faux, aurait dit l'autre. J'avais en tête des calculs de somme et autres données à conserver (comme de vrai données de traitement calculées au fur et à mesure), mais en fait ce n'est sans doute pas le cas le plus fréquent, et il faut éviter de mixer les concepts.

Et ça m'irait aussi de pousser jusqu'à ce que les form_ephemere_x n'arrivent même pas jusqu'au workflow. Mais je pense que ça ne tiendra pas. Le cas d'usage typique sera le request.GET.foo qui doit être un "champ caché", c'est-à-dire qui ne sera même pas utilisé en pré-remplissage d'un champ verrouillé. Et il y a aussi le calcul complexe évoqué plus haut par Marie, calcul pénible qui est déjà fait dans un champ éphémère et qu'on n'a pas envie de dupliquer dans le workflow... ça s'entend.

Pour m'assurer d'avoir bien suivi : ces variables "éphémères" ne seraient pas postées avec le formulaire et il faudrait les recalculer en arrivant dans le workflow ?

C'est ma position.

Ca ne colle pas avec le besoin de récupérer une variable de session ou passée en querystring, on va la perdre, du coup.

J'imaginais qu'elle serve dans le formulaire; pour quel usage ça serait utile d'avoir une donnée qui arrive via l'URL et persiste sans exploitation jusqu'au workflow ?

S'il y avait un usage, je pense que ça serait mieux couvert en ayant de manière automatique dans la demande l'enregistrement de l'URL d'accès initial, plutôt que donner une durée de vie excédant la saisie à ces variables.

Cas d'usages exposés par exemple dans les notes 4 et 8. Pour le 4, j'ai pu voir ce fonctionnement par ailleurs, pour les offres d'emploi, et il n'est pas utile d'aller récupérer les infos complémentaires dans le formulaire, mais c'est utile dans le WF.
En ce qui concerne le calcul, ce serait pénible de le refaire dans le WF, même si c'est faisable, on perd en maintenabilité (il faut penser à modifier un calcul à deux endroits).

Pour la note 4, "soit lui exposer ce champ en l'empêchant de le modifier (read-only)", on est donc déjà couvert. (pour la note 8 je serais à dire que ça s'appliquerait aussi).

Je pense que ça expose vraiment à plein de soucis (note 32).

Cela étant, mon intention initiale était dans la note 28 :

Je notais "éphémères", je préciserais dispos jusqu'au moment de la validation de la demande, et là y compris l'exécution initiale du workflow (même si techniquement ça va sans doute compliquer un peu la vie), pour ainsi facilement permettre de transférer ces variables dans des données de traitement pérennes.

c'est pour assurer le découplage que j'en suis venu ensuite à retirer ça; mais bon, je peux revenir dessus.

Tu notais :

Les avoir au-delà de la saisie ça va amener à avoir des workflows qui dépendent directement de celles-ci

Mais sur des formulaires complexes c'est déjà le cas, de toute façon ; et que l'on doive refaire un calcul manuellement en début de wf ou que l'on récupère le résultat de ce calcul via {{form_var_mon_champ_cache}}, ça revient au même : le wf est totalement dépendant du formulaire.

Je suis un peu perdue dans les propositions que tu fais et j'ai peur qu'on passe complètement à c$ôté du besoin initial, qui était, finalement : un champ caché à l'usager qui peut être rempli par une variable de session, une querystring, un texte/gabarit/calcul et qui peut être réutilisé dans la suite du formulaire. En fait ce champ est identique à n'importe quel autre, sauf qu'il est caché.

Je notais :

De mon côté j'étais à pencher pour ne pas passer par la mécanique des champs ici […]

Et c'est vraiment quelque chose que je ne souhaite pas parce que les champs amènent trop de fonctionnalités dont il faudra assurer le fonctionnement (si pas immédiatement petit à petit au fil de tickets).

Je vais arrêter de parler de champ car je vois que ça porte à confusion ; disons plutôt : une variable.
On aurait donc : une variable définie à un instant T dans un formulaire (instant T qui est défini par le fabricant du formulaire), qui peut être rempli par une variable de session, une querystring, un texte/gabarit/calcul et qui peut être réutilisé dans la suite du formulaire.

réutilisé dans la suite du formulaire

... suite du formulaire entendue comme étant y compris le workflow; ok j'entends.

Ma crainte notée plus haut c'est qu'il se trouvera un moment où il faudra rejouer une action de workflow sur une demande réalisée à un moment où la variable n'était pas définie, et ça va du coup appeler à la création d'une action similaire à "données de traitement", pour modifier ces variables, etc. sans fin. (et c'est pour ça que ma "solution" était de juste jamais ne les avoir dans le workflow). (note 32) (mais ok pour dire que mon avertissement posé, elles sont tout le temps dispo)

Frédéric Péters a écrit :

Ma crainte notée plus haut c'est qu'il se trouvera un moment où il faudra rejouer une action de workflow sur une demande réalisée à un moment où la variable n'était pas définie

Et je n'ai pas rebondi dessus parce que je n'ai pas compris de quoi tu parles, j'aurais dû. Quelle action par exemple ?

Une action qui contiendrait form_variable_intraformulaire_var_plop, que ce soit en condition, dans une action qui tape cette variable en donnée de traitement, peu importe.

Par exemple une prise de rendez-vous, avec possibilité d'annulation/changement de date, et le 10 janvier on modifie l'action pour faire référence à une de ces nouvelles variables, et c'est très bien pour les nouvelles demandes mais arrive une ancienne qui date d'avant le 10 janvier, et donc une demande qui a été soumise sans la variable en question, et là, si ça avait été une donnée de traitement, on aurait dit "faire une action globale qui la pose, comme ça elle existe partout y compris sur les anciennes demandes", et sur ces nouvelles variables, on ne pourrait pas dire ça. (et ça apparaitrait comme un manque et il y aurait alors ticket pour ajouter une action de workflow permettant de modifier ces variables).

J'ai envie de dire qu'on a la même problèmatique aujourd'hui avec un champ de formulaire qui débarquerait alors que la démarche est déjà utilisée : ça n'est pas dispo sur les anciennes démarches et puis voilà.
Non ?

Oui, tout à fait. La différence que je vois ici c'est qu'on imaginerait pas aller modifier un champ de la demande de l'usager, alors que ces nouvelles variables, comme techniques/invisibles, je m'imagine facilement la demande de pouvoir les modifier arriver.

Frédéric Péters a écrit :

La différence que je vois ici c'est qu'on imaginerait pas aller modifier un champ de la demande de l'usager, alors que ces nouvelles variables, comme techniques/invisibles, je m'imagine facilement la demande de pouvoir les modifier arriver.

Les modifier avec l'action "édition d'une demande" dans le workflow ? On a en effet un souci, car autant une valeur récupérée depuis une session ou une querystring (qui n'existera plus dans le contexte) doit être impérativement conservée, autant un calcul doit être potentiellement révisé. Et là, je n'ai pas de solution, à part peut-être ajouter une option "ne pas toucher à l'édition"/"vas-y recalcule" (qui va certainement complexifier les choses).

Je reprends après discussion, sur l'idée de ne pas introduire un nouveau type de variables, définies au niveau des pages.

On pourrait envisager le développement comme un nouveau type de champ (appelons-le "Donnée calculée", voire "Donnée de traitement"), ce champ serait paramétré avec un identifiant (pas même besoin d'un libellé) et un gabarit (pour calculer la valeur) (n'introduisons pas de python en 2021) + un paramétrage pré|post pour déterminer si l'évaluation se fait à l'entrée ou à la sortie de la page. (cf #27429#note-30).

Ça donnerait des variables form_var_whatever comme n'importe quel autre champ du formulaire, qui seraient disponibles tout le temps comme n'importe quel autre champ du formulaire, qui ne pourraient pas être modifiées par l'action "données de traitement", comme n'importe quel autre champ du formulaire.

Ce type de champ serait disponible pour les formulaires et les modèles de fiche, i.e. les endroits qui ont également la possibilité de champs "page", i.e. pas les données de traitement, pas les variables de workflow, pas les actions d'affichage de formulaire, pas les blocs de champs.

+ un paramétrage pré|post pour déterminer si l'évaluation se fait à l'entrée ou à la sortie de la page.

Plutôt que ce paramétrage, qui est vraiment juste là pour éviter qu'une valeur remplie par un request.GET ou similaire se perde, possibilité d'une option qui serait soit "figer la valeur initialement calculée" soit la complémentaire "recalculer selon les données du formulaire". (libellés à affiner)

Et pour préciser par rapport à ce que j'ai écrit dans certains commentaires plus haut, ces variables seraient bien tout le temps accessibles, tout le long de la vie de la demande.

Je suis ok avec cette spécification. Je vote pour nommer cela des « Données calculées » et je proposerai de les référencer comme « form_calc_* » parce que le mélange avec les form_var_ risque d'être plus perturbant qu'autre chose (à mon sens). Mais je ne suis pas bloqué, j'avais déjà perdu le combat pour les données de traitement ;-)

• besoin de remplir un champ par query string passée en url
• besoin de remplir un champ par calcul basé sur les valeurs des champs précédents
• besoin que la valeur de ce champ soit réutilisable plus loin dans le formulaire ou le workflow
• besoin que ce champ soit caché à l'usager

Pas testé : utilisation de session_var / besoin de remplir un champ par un calcul basé sur les filtres