<!- Fill in “repoName” and “repoURL” for the automatic install button →
Installer ce composant de thème
Description détaillée
Faites preuve de prudence avec les données sensibles dans ces champs. Les champs ne sont pas trouvés dans la source, mais pourraient être visibles si quelque chose se casse
J’ai deux utilisateurs, derek_test (à gauche) et anon9 (à droite). Les champs ID et Société sont tous deux renseignés dans leurs profils, mais un seul est visible par l’autre. derek_test peut voir ID et anon9 peut voir Société.
Que voient les utilisateurs qui ne sont pas connectés ? Donc, si le champ n’est visible que par les administrateurs, je m’attendrais à ce que les utilisateurs ne puissent pas le voir même après s’être déconnectés, n’est-ce pas ?
Y a-t-il une raison pour laquelle vous avez choisi le champ texte pour le paramètre de groupe au lieu d’une liste de groupes (group_list) ? C’est un peu plus pratique pour entrer des groupes car vous pouvez les sélectionner au lieu de taper le nom. Cependant, cela fonctionne avec l’ID, vous devez donc modifier un peu le code. Mais cela fonctionne toujours même si vous renommez le groupe.
Bonne remarque, je viens de le mettre à jour pour en tenir compte. Je peux confirmer que les utilisateurs déconnectés ne voient pas le champ.
Je vais être honnête et dire que j’ai fait cela avec Claude Code, mais il a dit que le type group_list n’est pas disponible dans un éditeur d’objets, seulement comme paramètre de niveau supérieur.
Donc, cela devrait ressembler à ceci, mais avec un nombre fixe de champs disponibles
Hein.. Bien que les paramètres dans l’éditeur d’objets aient accepté list_type:group, je n’ai pas pu dépasser une erreur :
J’ai essayé quelques transformations différentes mais je n’ai pas pu y arriver. Le verdict est que « Le type groups dans les schémas d’objets est documenté mais l’interface utilisateur n’est pas implémentée dans le frontend ».
J’ai vu cette erreur aussi, mais après avoir utilisé le bouton de réinitialisation pour réinitialiser tous les paramètres de l’objet, l’erreur n’est pas revenue
Donc tout va bien maintenant
Peut-être que cela n’a pas aimé le changement du type de paramètre sur une configuration existante
Pouvez-vous préciser ? Je ne vois pas le problème. Il a actuellement 1 et 2. Votre demande est-elle également de masquer les champs aux modérateurs/administrateurs ? Soit dit en passant, les administrateurs devraient créer le champ initialement.
Je viens de le tester à nouveau sur mon dépôt github local clair le plus récent et sur la solution hébergée avec la dernière version - seule la catégorie Admin est affectée et peut voir le champ Masqué si l’utilisateur est membre d’un groupe autorisé à voir ce champ. Même l’accès Modérateur (comme je le pensais auparavant, cela ne fonctionne pas)
Le cas :
Deux utilisateurs, admin et Alex_1
Groupe d’utilisateurs L2_verified
Champ utilisateur - Nom complet (Pour tous les utilisateurs, tous Activé, seule la recherche Désactivée)
Les deux utilisateurs ont des noms : Alex Admin et Alex
Paramètres du thème :
Inclure le composant sur ces thèmes (Foundation, Horizon)
Nom du champ : Nom complet
Groupes autorisés : L2_verified
Résultats :
Aucun des deux n’est membre de L2_verified - personne ne voit le champ Nom complet (même son propre Nom complet)
admin est membre de L2_verified - peut voir le Nom complet d’Alex_1 (et son propre Nom complet)
Alex_1 est membre de L2_verified - ne peut pas voir son propre Nom complet ni celui d’admin
Lorsque j’ai accordé admin à Alex_1 - il peut voir les deux Noms complets - le sien et celui d’admin
Merci pour cet excellent composant ! C’est une base fantastique pour gérer la confidentialité des utilisateurs sur Discourse.
J’ai développé une version spécialisée avec une visibilité bidirectionnelle (réciproque) basée sur votre travail. Dans notre communauté professionnelle, nous avions besoin d’un modèle de « Confiance Mutuelle » où les membres vérifiés peuvent voir les noms réels/données commerciales des autres, tout en restant complètement anonymes pour le grand public ou les utilisateurs non vérifiés.
Fonctionnalités clés de cette version :
Logique Réciproque : Un champ n’est révélé que si à la fois le spectateur et le propriétaire du profil appartiennent au groupe autorisé.
Supervision par le personnel : Les administrateurs et les modérateurs conservent une visibilité complète pour des raisons de sécurité et de modération.
Auto-visibilité : Les utilisateurs peuvent toujours voir leurs propres champs masqués, même s’ils ne font pas encore partie du groupe autorisé, afin de pouvoir gérer leur propre profil.
Confidentialité pair-à-pair : Cela garantit que même les utilisateurs vérifiés ne révèlent pas leur identité à quelqu’un qui n’a pas subi le même niveau de vérification.
Feuille de route : Dans les futures mises à jour, j’ai l’intention d’ajouter des paramètres de groupe granulaires pour définir exactement quels groupes peuvent voir et être vus (par exemple, permettre au Groupe A de voir le Groupe B, mais pas l’inverse).
Je suis actuellement en train de finaliser la documentation et prévois de publier ceci comme une variante autonome « Confidentialité Avancée » dans un sujet séparé une fois que j’aurai un accès complet à la catégorie Composants de Thème.
En attendant, si quelqu’un a besoin de cette logique bidirectionnelle, vous pouvez la consulter ici : GitHub :https://github.com/AirVetra/discourse-hidden-user-fields-bidirectional
Faites preuve de prudence avec les données sensibles dans ces champs. Les champs ne sont pas trouvés dans la source, mais pourraient être visibles si quelque chose se casse
Revoyez ces paramètres une fois les champs renseignés ou créez les autorisations à l’avance, afin que ces champs ne soient jamais exposés.
