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.
Related issues
History
Updated by Anaïs Ecuvillon over 1 year ago
- Related to Développement #63184: Conditionner un champ obligatoire en backoffice added
Updated by Anaïs Ecuvillon over 1 year ago
- Related to Développement #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 added
Updated by Stéphane Laget over 1 year ago
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.
Updated by Pierre Cros over 1 year ago
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é ?
Updated by Stéphane Laget over 1 year ago
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).
Updated by Frédéric Péters over 1 year ago
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".
Updated by Stéphane Laget over 1 year ago
oui pour moi aussi, #49041 serait suffisant sur ce sujet.
Updated by Anaïs Ecuvillon over 1 year ago
- Assignee set to Stéphane Guiet (retour le 28 avril 25)
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
Updated by Anaïs Ecuvillon over 1 year ago
- Related to Développement #49041: Caractère obligatoire d'un champ différent suivant saisie front ou backoffice added
Updated by Anaïs Ecuvillon over 1 year ago
- Related to Autre #84633: Amélioration de la saisie backoffice added