Nous travaillons à améliorer l’expérience d’intégration de notre communauté. Naturellement, nous aimerions utiliser les informations que nous connaissons sur l’utilisateur pour faire/montrer certaines choses en fonction des informations qu’il nous donne.
Aujourd’hui, nos utilisateurs commencent la création de leur compte via notre intégration OIDC en créant un compte auprès de notre entreprise. Ils fournissent leur e-mail, leur nom et leur nom d’utilisateur à OIDC avant qu’il ne les redirige vers Discourse.
Le problème
Nous aimerions maintenant leur donner des champs utilisateur supplémentaires à remplir, ce qui est formidable, car Discourse en propose ! Malheureusement, nous ne pouvons pas afficher de champs en fonction des réponses aux champs précédents. Par exemple, nous aimerions demander : « Quel rôle vous décrit le mieux ? » avec les options développeur, administrateur et analyste.
S’ils choisissent développeur, je veux bien sûr leur demander quelles sont leurs langues de programmation préférées. Je les ajouterai également plus tard au groupe d’utilisateurs développeurs.
S’ils choisissent analyste, je veux leur poser une série de questions différentes et les ajouter à un groupe d’utilisateurs différent.
Solution proposée
De nombreuses options de formulaire sur le web aujourd’hui proposent des champs de formulaire conditionnels (par exemple, où avez-vous entendu parler de nous ? si ‘autre’ est sélectionné, un champ supplémentaire apparaît pour dire pourquoi.). Ce serait formidable si vous commenciez dans une voie similaire (mais plus robuste) que celle que vous avez suivie avec les modèles de nouveaux sujets, bien qu’avec l’exigence supplémentaire de pouvoir dépendre de l’ID d’un autre champ, et spécifiquement de l’entrée de ce champ. Par exemple, cela pourrait ressembler à ceci :
- type: dropdown
id: user-type
choices:
- "Développeur"
- "Administrateur d'application"
- "Analyste"
attributes:
none_label: "Choisissez votre rôle..."
label: "Quelle option décrit le mieux votre emploi"
validations:
required: true
- type: dropdown
id: developer-type-programming-language
depends: user-type
choices:
- "Développeur"
choices:
- "Développeur"
- "Administrateur d'application"
- "Analyste"
attributes:
none_label: "Langage de programmation préféré..."
label: "Quel est le langage de programmation principal utilisé dans votre rôle ?"
validations:
required: true
Dans cet exemple, tous les utilisateurs seraient interrogés sur la première question. Si l’utilisateur sélectionne Développeur dans la liste déroulante, une deuxième question apparaîtrait sur le formulaire demandant quel est son langage de programmation préféré.
Cette amélioration des champs conditionnels pourrait être utilisée à la fois dans le processus d’intégration des utilisateurs et dans l’endroit initialement prévu pour les nouveaux sujets.
Vous pouvez jeter un œil à GitHub - discourse/discourse-authentication-validations qui fait exactement cela, sauf que pour la page d’inscription de l’utilisateur. Il ne semble pas trivial de l’adapter à la page des préférences de l’utilisateur où ces champs sont modifiés.
Mais vous demandez une fonctionnalité, pas une solution à votre problème immédiat.
La case à cocher en bas ajoute l’option d’authentification.
Ensuite, remplissez les réponses du déclencheur qui activeront les champs personnalisés utilisateur suivants. Dans mon cas, il s’agit d’un nombre de casques supérieur à Aucun.
Une fois remplis, ciblez les champs utilisateur personnalisés que vous souhaitez afficher. Dans mon exemple, si 1-6+, l’utilisateur sera invité à saisir les casques principaux et secondaires.
Ce serait formidable si cela était étendu aux modèles de formulaires expérimentaux.
Sera-t-il possible d’avoir ces conditions qui fonctionnent dans le profil utilisateur plutôt que uniquement sur la page de création de compte ? (Je suis à peu près sûr de comprendre que cela ne fonctionne que sur la page de création de compte - j’ai quelqu’un qui veut que les gens reviennent pour saisir des informations et que ces règles soient appliquées.)
Oui, c’est actuellement le seul endroit affecté par ce plugin.
Laissez-moi m’assurer que nous sommes sur la même longueur d’onde :
Souhaitez-vous la possibilité de mettre à jour des champs d’utilisateur personnalisés publics via /preferences/profile et appliquons-nous la même logique conditionnelle de masquage/affichage que celle que nous avons sur la modale de création de compte ?
Quelque chose comme, si la valeur du champ personnalisé 1 est afficher le champ personnalisé 2, alors afficher le second champ personnalisé ?
Oui. Je veux que toutes les custom_user_fields qui sont Editable after signup (Modifiables après inscription) aient les mêmes règles appliquées sur la page /preferences/profile.
Je pense que c’est ça. Les mêmes règles qui sont en vigueur sur la fenêtre modale de création de compte seraient en vigueur sur la page de profil.
Eh bien, pour vous, peut-être ! J’ai essayé et je me suis rapidement perdu. Il semblait que cela devrait être presque aussi facile que de copier certaines choses sur la page des préférences, mais lesquelles étaient plus que ce que je pouvais rapidement comprendre.
