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)
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 !
Persistence d'une info passée dans la query string.
Saisie 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...)
Peut-être à plutôt rapprocher des questions spécifiques à la carto, quand existe un champ carto et un champ adresse, lequel compte ?
Si c'est la carte qui compte, si l'adresse est juste affichée à titre informatif, peut-être une option sur les champs carte "afficher l'adresse sélectionnée" ?
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).
Même situation que le premier, persistence d'une info passée dans la query string
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.
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).
Genre hidden ou readonly, ça donne une fausse impression au créateur du formulaire, qui n'imagine alors pas qu'en fait l'usager garde la main sur ces champs.
Ça a été fait pour les attributs de profil, "vérifié" pourrait porter davantage d'information que "lecture seule" (l'idée était que dans le backoffice apparaisse une marque à côté de ces champs).
Problème de volatilité (cf note-4 et note-8).