Désactiver « activer les noms » fait que l'administrateur agit de manière étrange

La désactivation du paramètre enable_names supprime le nom complet partout dans l’interface graphique.
Sauf dans la vue administrateur - jusqu’ici tout va bien.
Cela semble fonctionner, mais ce n’est pas le cas.

  • au début, le nom n’apparaît pas
  • vous pouvez le modifier
  • il apparaît alors mais n’est jamais sauvegardé

Voir la vidéo

Version : tests-passed ce matin.

8 « J'aime »

Lors de la modification d’un utilisateur dans le menu d’administration. La modification du Nom de l’utilisateur est enregistrée mais après actualisation, rien n’a été sauvegardé.

Aucun nom affiché dans Nom

Modifier et enregistrer. Actualiser la page, aucun nom enregistré comme sur l’image ci-dessus.

Tests en cours réussis et à jour.

3 « J'aime »

Le paramètre enable names est-il activé ?

5 « J'aime »

Non, pas activé. Donc bug récent. @JammyDodger peux-tu fusionner ce sujet avec celui de Richards ?

3 « J'aime »

Je ne suis pas sûr que ce soit récent

1 « J'aime »

Un administrateur devrait pouvoir voir et mettre à jour le nom, quel que soit le paramètre enable_names. :thinking:

4 « J'aime »

Assez récent, car je n’avais pas remarqué ce changement de comportement jusqu’à récemment. (Même si on dirait que le problème a peut-être été signalé pour la première fois il y a 4 ans ?)

Le message de Richard de janvier.

Certes, les 2 forums que j’utilise ont 4 ans et 7 ans.

C’est probablement pourquoi je n’ai pas remarqué le changement lorsqu’il s’est produit, car je ne modifie/corrige pas souvent les détails pour un utilisateur.

Il semble qu’ils aient peut-être besoin d’ajouter un paramètre ? Donc le nom est activé et le choix de l’afficher globalement ou non.

Comme mentionné dans la discussion que vous avez liée, le nom complet devrait être affiché au minimum à l’utilisateur et à l’administrateur.

2 « J'aime »

Remonter


L’administrateur devrait pouvoir afficher le contenu du champ Nom. La photo montre mon compte, mais même en modifiant ce champ et en enregistrant, il se vide lors d’un rafraîchissement.

J’étais sûr que nous en avions discuté plus tôt, mais j’ai eu du mal à trouver avec les termes de recherche.
Le seul paramètre du site est de le rendre visible et de l’ajouter à toutes les zones du site affichées.

L’administrateur devrait toujours pouvoir afficher ce champ utilisateur. Et selon moi, ce détail devrait également apparaître dans le menu des préférences utilisateur « Compte », car il fait partie des détails de leur compte.

3 « J'aime »

D’accord, j’ai trouvé le paramètre que @Moin a mentionné, il ne le remplit pas pour tout le monde. Juste pour l’utilisateur actuel sur sa carte.

Les noms activés fonctionnent. Mais toute information que les utilisateurs ont entrée précédemment dans ce champ est vide ok, certains n’ont pas rempli ce champ. Mystère résolu.

Il faudrait peut-être mieux clarifier ce paramètre. À mon avis, il devrait être activé par défaut.

J’ai découvert que la raison est

class BasicUserSerializer < ApplicationSerializer
  # ...
  def include_name?
    SiteSetting.enable_names?
  end

Il n’y a pas de jugement spécial sur l’administrateur.

Mais je suis curieux, comment cela devrait-il être changé ? Le modérateur peut-il changer le nom d’utilisateur ? ou juste l’administrateur ? :thinking:

3 « J'aime »

Je pense que oui

3 « J'aime »

Je me demande si les modérateurs devraient être affectés par la fonction « masquer partout » de la description… peut-être qu’ils ne devraient pas pouvoir voir le nom, même dans le panneau d’administration ?

mise à jour : Selon cette description, l’administrateur ne devrait pas non plus pouvoir la voir

1 « J'aime »

Je suggérerais d’en faire une bascule pour les modérateurs complets. L’administrateur, cependant, comme discuté, devrait toujours pouvoir voir ce champ.

Après avoir activé les noms, cela brise la confidentialité car il inclut maintenant le vrai nom dans les e-mails. À moins qu’il n’y ait un paramètre supplémentaire ? Je n’en ai pas trouvé après qu’un membre ait signalé que les vrais noms se trouvaient dans les notifications par e-mail au lieu de simplement le nom d’utilisateur.

Par exemple, un e-mail à l’utilisateur d’une réponse de ma part a envoyé le vrai nom dans l’e-mail.

Ensuite, si cela masque le champ à tous, cela devrait désactiver l’utilisation de ce champ car même le membre ne peut pas voir ce détail.

Le forum de la branche stable dont je m’occupe également n’est pas affecté par le changement de comportement discuté ici.

Où puis-je corriger l’e-mail pour qu’il n’envoie pas de vrais noms et utilise plutôt le nom d’utilisateur ?

Et quelle CSS utiliserais-je pour que seul l’utilisateur actuel voie son propre vrai nom sur la carte utilisateur ?

1 « J'aime »

Je pense que les modérateurs peuvent également voir et modifier les champs personnalisés des utilisateurs pour lesquels « modifiable après l’inscription » et « afficher sur le profil public » sont désactivés. Dans ce cas, l’utilisateur ne peut pas voir son propre champ, mais les modérateurs le peuvent. Peut-être serait-il cohérent que le champ nom se comporte de la même manière.

Ensuite, la description pourrait être modifiée. Par exemple :

Afficher le nom complet de l’utilisateur à tout le monde sur son profil, sa carte utilisateur et ses e-mails. Si désactivé, le nom complet ne sera affiché qu’aux membres du personnel sur le profil de l’utilisateur.

2 « J'aime »

Merci, Richard ! Je suis en mesure de reproduire le problème que vous signalez, et nous allons le corriger. :+1: Les administrateurs devraient toujours pouvoir voir et gérer le nom des utilisateurs, même s’il n’est pas affiché à divers endroits sur le forum.

En ce qui concerne le reste de cette conversation, je constate qu’il y a encore du travail à faire pour rassembler ces paramètres et les rendre plus faciles à comprendre. Je vais ajouter cela à notre liste pour une investigation plus approfondie.

En attendant, j’ai créé une petite PR pour supprimer ce langage ambigu dans la description du paramètre du site enable names.

3 « J'aime »

Je pense qu’il vaut la peine de décortiquer cela et d’identifier les décisions que nous devons prendre, puis de créer plusieurs tâches. Je vais me les assigner pour essayer de trouver une solution.

2 « J'aime »

Il semble y avoir trois points d’action pour ce sujet :

  1. Toujours permettre aux administrateurs de voir et de modifier le nom complet de l’utilisateur, même lorsque le paramètre du site enable_names est désactivé.
  2. Ne pas inclure le nom complet de l’utilisateur dans les e-mails lorsque le paramètre du site enable_names est désactivé.
  3. Changer la description du paramètre du site enable_names pour indiquer qu’il ne s’agit pas d’une fonctionnalité de sécurité. Les administrateurs et les modérateurs peuvent toujours le voir, et ceux qui connaissent le .json peuvent également le trouver. Si les sites souhaitent permettre aux utilisateurs d’avoir l’anonymat, ils ne devraient pas mettre leur vrai nom dans le champ nom.

Nous allons examiner (1) et (2).

Quant à (3), nous devons trouver un meilleur langage qui ne soit pas ambigu et inclure un lien vers un sujet de documentation ici sur meta pour plus de détails. Quelque chose comme ceci ?

Afficher le nom complet des membres sur les profils, les cartes utilisateur et dans les e-mails. Notez qu’il ne s’agit pas d’une fonctionnalité de sécurité. Les administrateurs et les modérateurs peuvent toujours voir les noms, et ils peuvent également être découverts via le .json. En savoir plus

4 « J'aime »

J’ai commencé à travailler sur une implémentation de Restrict exposure of full name to certain groups, et je suis tombé sur ce sujet, qui recoupe complètement ce que j’essaie de faire.

Mon approche consiste à remplacer SiteSetting#enable_names par un nouveau Guardian#can_see_full_names?, dans les contextes appropriés. Ce nouveau prédicat de gardien vérifie le contexte de l’utilisateur par rapport à un nouveau paramètre de site, full_names_visible_to_groups.

Je ne veux pas marcher sur les plates-bandes de qui que ce soit (ou dupliquer le travail) — y a-t-il des mises à jour sur le statut/la planification de (1)/(2)/(3)/etc ci-dessus, et y a-t-il des travaux/codes non publiés (c’est-à-dire non présents dans le dépôt main) dont je devrais être au courant ?

(1) et (2) sont sur notre liste mais n’ont pas encore été priorisés ni traités. (3) semble être une bonne idée, mais nous n’avons pas encore effectué ce changement non plus.

Votre implémentation n’est pas mauvaise, mais peut-être attendez un peu pour laisser à l’ingénieur de cette équipe une chance de répondre ici.

Cependant, une question produit pour vous… pourquoi cherchez-vous à donner à certains groupes l’accès aux noms complets et pas à d’autres ? Pouvez-vous expliquer votre cas d’utilisation plus en détail ?