This guide explains how to create and configure custom user fields in Discourse, including how to add them to the signup form, user profiles, and user directory.
Required user level: Administrator
Custom user fields allow you to collect additional information from your users beyond the standard profile fields. These fields can be displayed on user cards, user summary pages, and even retrieved using the Data Explorer plugin. This guide will walk you through the process of creating and configuring custom user fields.
Adding a user field
Go to Admin > Community > User Fields (discourse.example.com/admin/config/user-fields).
If you haven’t created any user fields yet, you’ll see this screen:
Optional - Optional fields may be left empty by users
For all users - When a field is required by all users, every account, including logged on users will be forced to fill it. This is very useful for cases such as a terms-of-service (ToS) requirement.
On signup - All new account will be required to fill the field.
Additionally, at the bottom of the creation form, you’ll find these options:
Editable after signup: Allows users to update the field from their profile page
Required at signup: Makes the field mandatory during account creation
Show on public profile: Displays the field value on the user’s summary page
Show on user card: Shows the field value on the user card
Searchable: Enables searching for users based on this field’s value in the user directory
Show on public profile
When enabled, the field value will be shown on the user’s profile page:
Hmm. C’est intéressant. Je pense qu’il y a une solution à venir pour le problème Missing images at Meta.discourse.org, donc j’espère qu’il sera résolu par cela.
Y a-t-il un paramètre que je dois modifier pour spécifier la longueur maximale d’un champ utilisateur personnalisé ? Pour l’instant, dans ce champ « Test » que j’ai créé comme champ utilisateur de test, je ne peux même pas saisir un seul caractère sur mon profil utilisateur (ni même « Test », comme indiqué).
Les URL étant du texte, le champ texte fonctionne techniquement, @Vaping_Community. Cependant, vous demandez peut-être des détails supplémentaires tels que la validation de la valeur ou similaire.
Vous pourriez rechercher ou créer un sujet Feature avec ce que vous avez en tête.
Est-il possible d’intégrer une revendication personnalisée de mon SSO Auth0 à un champ personnalisé ? Actuellement, l’utilisateur saisit les informations du champ dans Auth0, puis doit les saisir une seconde fois lors de l’inscription. J’aimerais que la valeur soit mappée si possible.
Existe-t-il un moyen de vérifier le nom du champ dans la base de données ? Par exemple, nous avons un champ prénom, j’ai essayé custom.firstname, custom.first_name et custom.firstName, aucun d’entre eux n’a permis de remplir les champs sur l’écran d’inscription.
J’ai vérifié les journaux d’erreurs pour confirmer que les champs de jeton arrivent comme indiqué ci-dessus.
La syntaxe doit être custom.user_field_x, où x est l’ID numérique du champ affiché dans /admin/config/user-fields/{x}/edit.
Cette fonctionnalité de mappage n’est pas directement disponible dans le plugin Auth0.
Cela dit, il existe toujours des options pour réaliser ce que vous décrivez :
créer un composant de thème. Vous pouvez ajouter un petit script front-end qui synchronise automatiquement un champ utilisateur personnalisé Discourse avec une valeur déjà stockée dans Auth0. Par exemple, lorsqu’un utilisateur se connecte et que le champ est vide, le script peut appeler un point de terminaison sécurisé (une petite fonction cloud) qui récupère la valeur du champ depuis Auth0 et met à jour le profil Discourse via l’API.
utiliser des outils d’automatisation. Vous pourriez également utiliser des services d’automatisation externes comme Zapier ou Make pour effectuer cette synchronisation en dehors de Discourse. L’avantage est que vous n’avez pas à écrire/maintenir de code, mais seulement à payer pour le service tiers.
développement personnalisé. Nous pouvons étendre le plugin Auth0 lui-même pour prendre en charge nativement le mappage des revendications personnalisées dans les champs utilisateur lors de la connexion, ou créer un plugin personnalisé qui fonctionne en parallèle avec le plugin Auth0.
Un inconvénient évident de l’approche par composant de thème est que vous devrez écrire et maintenir vous-même le code personnalisé, tout en faisant attention du point de vue de la sécurité pour éviter d’introduire des bogues ou des vulnérabilités potentielles. Honnêtement, ce n’est pas une solution que je recommanderais pour un site de production comme le vôtre.
Si j’étais à votre place, je pencherais davantage pour la deuxième option, en utilisant des outils tiers, ou j’envisagerais de soumettre une demande de fonctionnalité ou une demande de travail personnalisé (en fonction de l’évaluation de nos chefs de projet) pour améliorer le plugin Auth0 lui-même.
Si vous souhaitez explorer la dernière option, nous pouvons poursuivre la discussion en privé.