Autre #82668
Conditionner le caractère obligatoire ou optionnel d'un champ
0%
Description
On en a parlé lors de l'EOCamp, il serait utile que le caractère obligatoire ou optionnel d'un champ puisse être conditionné.
Aujourd'hui on contourne ça avec deux champs ayant le même identifiant. Par exemple :- le champ A optionnel avec une condition d'affichage en cas de saisie BO ;
- le champ B obligatoire avec une condition d'affichage en cas de saisie FO.
Stefan et StephL ont indiqué que cela serait utile pour Publik famille, Publik notification et Publik association.
Je les laisse exposer ici les cas d'usage détaillé.
Mis à Autre, car encore au stade de la discussion.
Demandes liées
Historique
Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a 6 mois
- Lié à Development #63184: Conditionner un champ obligatoire en backoffice ajouté
Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a 6 mois
- Lié à Development #72767: pouvoir déterminer si le form_user provient d’un compte authentic créé à l’aide d’un courriel ou d’un numéro de téléphone mobile ajouté
Mis à jour par Stéphane Laget il y a 6 mois
Le cas d'usage évident c'est qu'on peut légitimement imposer un champ courriel obligatoire en front-office mais que ce même champ ne peut pas être obligatoire en saisie backoffice lorsque l'agent, au guichet ou au téléphone, saisit une demande pour le compte de l'usager.
Le contournement qui consite à mettre en place 2 champs différents (avec ou sans le même identifiant) s'avère désastreux à l'usage lorsque cette demande est utilisée pour créer des sous-demandes ou des fiches.
L'autre contournement relève aussi du bricolage : on met un champ non obligatoire avec un libellé comportant une astérisque (ie "Email*"), pour faire croire à l'usager que le chapp est obligatoire alors qu'il ne l'est pas en vrai, et on vérifie le contexte (fo/bo) en condition de sortie de page.
Mis à jour par Pierre Cros il y a 6 mois
Stéphane Laget a écrit :
Le contournement qui consite à mettre en place 2 champs différents (avec ou sans le même identifiant) s'avère désastreux à l'usage lorsque cette demande est utilisée pour créer des sous-demandes ou des fiches.
Tu peux expliquer la cata pour le cas d'usage donné ?
Mis à jour par Stéphane Laget il y a 6 mois
Quand tu crée des sous-demandes, ou tu modifie des sous-demandes, tu te retrouves à avoir deux champs (qui en plus se nomment pareil).
Mis à jour par Frédéric Péters il y a 6 mois
Si l'intérêt est uniquement le côté backoffice/frontoffice (plutôt que poser le caractère "obligatoire" sur base d'une condition quelconque), il y a #49041 avec une proposition qui simplement étend l'option "Obligatoire".
Mis à jour par Stéphane Laget il y a 6 mois
oui pour moi aussi, #49041 serait suffisant sur ce sujet.
Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a 6 mois
- Assigné à mis à Stéphane Guiet
Frédéric Péters a écrit :
Si l'intérêt est uniquement le côté backoffice/frontoffice (plutôt que poser le caractère "obligatoire" sur base d'une condition quelconque), il y a #49041 avec une proposition qui simplement étend l'option "Obligatoire".
ce ticket, de nos échanges lors de l'eocamp allait au delà.
Exemple avec une condition selon le type de compte de l'usager (création avec un num tel ou avec une adresse électronique).
Concernant le cas d'usage famille, faudrait voir avec Stef, je n'ai plus en tête le besoin
Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a 5 mois
- Lié à Development #49041: Caractère obligatoire d'un champ différent suivant saisie front ou backoffice ajouté
Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a 5 mois
- Lié à Autre #84633: Amélioration de la saisie backoffice ajouté