Project

General

Profile

Development #27429

Permettre les champs lecture seule / caché / etc.

Added by Laurent Séguin about 3 years ago. Updated 10 days ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Category:
Fabriques et traitement (wcs)
Target version:
Start date:
19 Oct 2018
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No
Club:
Yes

Description

En tant qu'administrateur fonctionnel je veux verrouiller certains champs de mon formulaire afin d’empêcher l'usager d'en modifier la valeur.

// Lister tous les cas d'usage connus


Related issues

Related to w.c.s. - Development #39167: option "lecture seule"Solution déployée22 Jan 2020

Actions
Related to w.c.s. - Development #43369: Mise à jour d'un champ pré-rempliFermé

Actions
Related to Publik - Development #45348: Pré-remplissage de champs Texte et Liste : réinitialisation après changement de conditionFermé22 Jul 202013 Nov 2020

Actions
Related to w.c.s. - Development #52110: champ de type "donnée calculée"Solution déployée16 Mar 202107 May 2021

Actions

History

#1

Updated by Thomas Noël about 3 years ago

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

#2

Updated by Benjamin Dauvergne about 3 years ago

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.

#3

Updated by Frédéric Péters about 3 years ago

Ç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.

#4

Updated by Stéphane Laget about 3 years ago

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.

#5

Updated by Pierre Cros about 3 years ago

  • Club set to Yes
#6

Updated by Frédéric Péters about 3 years ago

  • Status changed from Nouveau to Information nécessaire

"Information nécessaire" pour "lister tous les cas d'usage connus" de la description.

#7

Updated by Victor Claudet about 3 years ago

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...)

#8

Updated by Benjamin Dauvergne about 3 years ago

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)

#9

Updated by Stéphane Laget about 3 years ago

Cas d'usage à Grenoble :
Une demande "complexe" d'autorisation de manifestation qui doit être faite en 2 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.
#10

Updated by Frédéric Péters almost 3 years ago

  • Subject changed from Permettre les champs readonly to Permettre les champs lecture seule / caché / etc.
#11

Updated by Benjamin Dauvergne almost 3 years ago

Cas d'usage MinInt:
  • 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).
#12

Updated by Pierre Cros almost 3 years ago

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.

#13

Updated by Pierre Cros about 2 years ago

  • Target version changed from 2019 to 2020
#15

Updated by Frédéric Péters almost 2 years ago

#16

Updated by Frédéric Péters almost 2 years ago

  • Status changed from Information nécessaire to En cours
#17

Updated by Marie Kuntz over 1 year ago

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.

#18

Updated by Frédéric Péters over 1 year ago

#19

Updated by Frédéric Péters over 1 year ago

  • Related to Development #45348: Pré-remplissage de champs Texte et Liste : réinitialisation après changement de condition added
#20

Updated by Pierre Cros 12 months ago

  • Target version changed from 2020 to 2021
#21

Updated by Mikaël Ates 12 months ago

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.

#22

Updated by Marie Kuntz 10 months ago

En éliminant les cas d'usage qui avaient plutôt besoin des champs verrouillés, j'arrive à ce périmètre :
  • 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.

#23

Updated by Mikaël Ates 10 months ago

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"
#24

Updated by Marie Kuntz 10 months ago

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

#26

Updated by Frédéric Péters 10 months ago

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".

#27

Updated by Marie Kuntz 10 months ago

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)

#28

Updated by Frédéric Péters 10 months ago

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.

#29

Updated by Marie Kuntz 10 months ago

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 ?

#30

Updated by Frédéric Péters 10 months ago

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.

#31

Updated by Thomas Noël 10 months ago

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).

#32

Updated by Frédéric Péters 10 months ago

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.

#33

Updated by Thomas Noël 10 months ago

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.

#34

Updated by Marie Kuntz 10 months ago

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 ?

#35

Updated by Frédéric Péters 10 months ago

C'est ma position.

#36

Updated by Marie Kuntz 10 months ago

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.

#37

Updated by Frédéric Péters 10 months ago

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.

#38

Updated by Marie Kuntz 10 months ago

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).

#39

Updated by Frédéric Péters 10 months ago

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.

#40

Updated by Marie Kuntz 10 months ago

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é.

#41

Updated by Frédéric Péters 10 months ago

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).

#43

Updated by Marie Kuntz 10 months ago

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.

#44

Updated by Frédéric Péters 10 months ago

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)

#45

Updated by Marie Kuntz 10 months ago

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 ?

#46

Updated by Frédéric Péters 10 months ago

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).

#47

Updated by Marie Kuntz 10 months ago

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 ?

#48

Updated by Frédéric Péters 10 months ago

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.

#49

Updated by Marie Kuntz 10 months ago

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).

#50

Updated by Frédéric Péters 10 months ago

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.

#51

Updated by Frédéric Péters 10 months ago

+ 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.

#52

Updated by Thomas Noël 10 months ago

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 ;-)

#55

Updated by Frédéric Péters 8 months ago

#56

Updated by Brice Mallet 6 months ago

  • Status changed from En cours to Résolu (à déployer)

Le développement "donnée calculée" a été livré (#52110), resterait à vérifier la bonne couverture des cas d'usage par cette nouvelle fonctionnalité

#57

Updated by Marie Kuntz 6 months ago

Testé et validé sur :
  • 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

#58

Updated by Mikaël Ates 10 days ago

  • Status changed from Résolu (à déployer) to Fermé

Also available in: Atom PDF