Project

General

Profile

Development #27429

Permettre les champs lecture seule / caché / etc.

Added by Laurent Séguin over 1 year ago. Updated about 2 months ago.

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

0%

Patch proposed:
No
Planning:
No
Demande du club utilisateur:
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ée 22 Jan 2020
Related to w.c.s. - Development #43369: Mise à jour d'un champ pré-rempli Nouveau

History

#1 Updated by Thomas Noël over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

  • Demande du club utilisateur set to Yes

#6 Updated by Frédéric Péters over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

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

#11 Updated by Benjamin Dauvergne over 1 year 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 over 1 year 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 8 months ago

  • Target version changed from 2019 to 2020

#15 Updated by Frédéric Péters 6 months ago

#16 Updated by Frédéric Péters 6 months ago

  • Status changed from Information nécessaire to En cours

#17 Updated by Marie Kuntz about 2 months 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 about 2 months ago

Also available in: Atom PDF