J’ai donné quelques informations sur le cas d’utilisation dans Restrict exposure of full name to certain groups. Nous utilisons Discourse pour faciliter la discussion sur l’éducation publique locale ; la base d’utilisateurs ciblée est principalement composée de parents et d’autres membres de la communauté locale. Nous voulons trouver un équilibre :
D’une part, rendre le site ouvert à la navigation anonyme (afin que les moteurs de recherche puissent l’indexer, qu’il soit accessible même aux non-membres, qu’il soit ouvert/transparent par principe, …)
D’autre part, éviter de rendre inutilement des informations personnelles identifiables accessibles aux robots d’exploration et aux visiteurs occasionnels non-membres — nous voulons permettre aux gens de partager leurs noms au sein de la communauté et nous voulons répondre à la réticence que beaucoup de gens ont à le faire.
À l’origine, il semblait que désactiver « Afficher le nom sur les messages » et activer « Cacher les profils utilisateurs au public » suffirait à bloquer les fuites de noms aux utilisateurs anonymes — mais nous avons ensuite réalisé que ce n’était pas le cas. (Et nous avions déjà promis aux gens via les CGU et la FAQ que nous le ferions. )
Refuser l’accès aux noms complets uniquement aux utilisateurs anonymes ferait l’affaire. Mais, comme il est tout aussi facile de lier l’accès à l’appartenance à un groupe, je me suis dit autant le faire — ce qui ouvre la possibilité, sur notre site, de restreindre l’accès à >=TL1, ce qui est encore mieux. (Actuellement, nous exigeons une invitation pour s’inscrire, mais nous voulons nous en débarrasser.)
En examinant ce problème/sujet, j’ai vu d’autres mentions de demandes identiques ou similaires, par exemple, « nous voulons seulement que tel ou tel groupe puisse voir les noms »… donc cela réglerait aussi ces cas d’utilisation.
Une question pour vous (que vous pourriez même considérer comme une question produit !) :
Le réglage enable_names est-il censé signifier « Ne pas montrer les noms complets aux utilisateurs » ou plutôt « Ce site n’utilise pas les noms complets, point final » ?
J’ai l’impression (à partir du code lui-même, et à partir de sujets/problèmes comme celui-ci) qu’il y a un manque de clarté sous-jacent sur ce point — et certaines personnes l’ont compris d’une manière, et d’autres d’une autre.
D’accord. Les administrateurs devraient pouvoir accéder au nom complet sans avoir à activer ou désactiver l’interrupteur. Il y a des raisons particulièrement importantes (du moins pour notre forum) de cacher les noms réels.
Merci à tous ceux qui ont contribué à cette discussion. Je voudrais juste demander respectueusement si ce problème sera résolu dans une prochaine version, ou au moins reconnu comme une régression connue.
Désactiver l’activation des noms casse actuellement une fonctionnalité d’administration clé d’une manière qui semble involontaire, et le manque de clarté quant à savoir si cela est intentionnel ou s’il s’agit d’un bug rend difficile notre planification. Pour ceux d’entre nous qui exploitent des sites de production où les noms d’utilisateur sont préférés aux noms complets, cette limitation introduit de réelles frictions et un comportement inattendu.
Je comprends que les priorités doivent être équilibrées, mais il serait extrêmement utile d’obtenir une mise à jour de l’équipe pour savoir si cela est pris en compte. Merci d’avance pour toute information que vous pourrez fournir.
Salut, @tobiaseigen, y a-t-il des retours d’ingénierie à ce sujet ? (Cela fait 3 mois — mais j’étais aussi occupé par d’autres choses et j’ai perdu de vue cela moi-même, donc je ne peux pas me plaindre.)
Je pourrais commencer à soumettre des pull request cette semaine pour rendre la conversation plus concrète — mais je crains qu’elles ne restent sans révision, et j’aimerais aussi avoir des retours sur certains aspects de mon approche.
@RGJ@chrismalone et @mdoggydog Merci infiniment pour votre contribution. Nous avons toujours besoin de ce correctif et sommes reconnaissants envers tous ceux qui travaillent sur ce problème.
Ouais honnêtement, je suis surpris que cela n’ait pas eu plus d’attention. Je comprends mal le fait d’être Leary pour faire une RP sans savoir si elle sera examinée et potentiellement mise en œuvre.
Bien qu’une RP, j’imagine, pourrait peut-être devenir un plugin, mais alors cela limite davantage cette option à l’auto-hébergement.
@mdoggydog On dirait que votre solution ici consiste à remplacer le paramètre enable names par un paramètre qui prend une liste de groupes, et les noms des membres ne sont visibles que par ces groupes.
Notez que cela devrait toujours respecter le paramètre display name on posts (et tout autre paramètre similaire qui pourrait exister), de sorte que même les groupes autorisés ne voient pas le nom sur les publications si ce paramètre est désactivé.
De plus, voici d’autres choses que nous devons corriger/modifier ici en tant qu’effets indirects :
Les noms doivent toujours être visibles dans la vue d’administration d’un profil d’utilisateur. Ce sera le cas quels que soient les paramètres.
Les noms ne doivent apparaître dans les e-mails que si l’utilisateur fait partie d’un groupe autorisé.
Ce qui précède devrait résoudre les problèmes actuels, tout en rendant cette fonctionnalité plus flexible et utile.
Est-ce que cela ressemble à ce que vous proposez ici ? Si c’est le cas, nous serions certainement heureux d’examiner toute demande de tirage (PR) que vous soumettez avec cette mise à jour incluse.
Le code que j’ai écrit ne supprime pas le paramètre enable names,[1] mais s’y ajoute :
Ajouter un paramètre full_names_visible_to_groups (qui inclut admins et moderators comme valeurs obligatoires).
Ajouter une méthode can_see_full_names? à Guardian, qui effectue une conjonction logique (and) de enable_names et de l’appartenance au groupe dans full_names_visible_to_groups.
Utiliser cette nouvelle méthode dans tous les endroits appropriés où un nom complet est exposé/émis par le serveur.
Les points 1 et 2 étaient faciles. Le point 3 est plus compliqué, et je sais que j’ai rencontré des obstacles que je ne savais pas comment résoudre sans obtenir de conseils/orientations. Je dois revenir en arrière et examiner mon code et mes notes en profondeur. (Cela fait plus de 2 mois que je ne m’y suis pas plongé. )
(Si je me souviens bien, display name on posts et les paramètres similaires sont des paramètres côté client, qui affectent la présentation des données reçues du serveur. En d’autres termes, une restriction supplémentaire à ce que le serveur émet.)
Je pense que le point (1) est pris en charge si enable_names est vrai, ce qui sera probablement ce que presque tout le monde voudra une fois que le nouveau paramètre par groupe sera disponible.[2]
Je pense avoir rencontré et traité le point (2) — en grande partie.[3]
Je me souviens d’autres cas où des noms complets sont divulgués.[4]
Quoi qu’il en soit, je vais revoir mes notes et essayer de soumettre des PR cette semaine, et en même temps, je vais déterrer les questions ouvertes/les points en suspens.
…pour un certain nombre de raisons, notamment : (a) je n’étais pas sûr de l’intention réelle du paramètre (voir ma question dans un message précédent ci-dessus), et (b) le laisser en place offre une voie de mise à niveau incrémentielle plus sûre. ↩︎
…si l’on considère que enable_names = false signifie “Ce site n’utilise pas les noms complets de quelque manière que ce soit”. ↩︎
Par exemple, lorsqu’un e-mail d’invitation est envoyé à une adresse (qui n’est évidemment pas associée à un utilisateur, sinon il n’aurait pas besoin d’invitation), l’e-mail inclut-il le nom complet de l’invitant ou non ? ↩︎
Par exemple, oneboxer.rb, lors de la création d’une “onebox” d’un utilisateur local, écrit le nom complet dans le contenu du message “cuit”, ce qui le rend visible par tous et n’importe qui, pour toujours. ↩︎
Cette PR est une condition préalable pour les suivantes, garantissant que les instances Guardian sont effectivement transmises d’un sérialiseur à l’autre. Les détails se trouvent dans la PR/le message de commit. La discussion sur cette PR peut commencer pendant que je prépare la suivante.
Mon aventure sur le mini-compte GitHub
…enfin, il y était jusqu’à ce que je tape l’URL dans la boîte d’édition ici… et ensuite mon compte entier a été soudainement suspendu.
J’ai déposé une demande de réintégration et je mettrai à jour ceci lorsque j’aurai une mise à jour.
13 heures plus tard, j’ai reçu un e-mail disant, en gros : « Parfois, cela arrive ; tout va bien maintenant. » Très kafkaïen. Mon compte a disparu du site — au point que des messages que j’avais publiés dans Issues/PR il y a des années ont disparu, laissant derrière eux des conversations mystérieuses à sens unique, avec quelques citations fantomatiques comme seule preuve que quelqu’un d’autre (moi) y était.
Cela semble horriblement excessif, non seulement pour le compte suspendu, mais aussi pour tous les projets dont des pans de leur histoire ont été discrètement effacés.
Je réalise que cela va impliquer également la coordination des changements dans les dépôts de plugins Discourse — ce qui signifie une chaîne de PR, dans une sorte d’ordre de l’intérieur vers l’extérieur, pour s’assurer que les tests passent toujours (et, bien sûr, que main est toujours fonctionnel).
J’imagine que la séquence ressemblerait à ceci (où CORE signifie « PR dans discourse/discourse » et PLUG signifie « PR dans les dépôts de plugins officiels ») :
Appliquer le transfert de portée du sérialiseur (aucun changement fonctionnel attendu)
a. CORE Implémenter la vérification de la portée du sérialiseur, désactivée par défaut
b. PLUG Corrections pour le transfert de portée
c. CORE Corrections pour le transfert de portée, et activer la vérification de la portée par défaut
Fournir de manière préemptive des Guardians (en remplaçant les espaces réservés) aux endroits nécessaires pour la phase 4 (aucun changement fonctionnel attendu)
CORE Corrections des espaces réservés
PLUG Corrections des espaces réservés
Implémenter un simple Guardian#can_see_full_names? qui dépend uniquement de enable_names(aucun changement fonctionnel attendu)
CORE Ajouter une méthode à Guardian
Utiliser can_see_full_names? partout où le nom complet est émis (en remplaçant l’utilisation brute de enable_names de manière appropriée) (pourrait avoir un changement fonctionnel)
CORE utiliser la nouvelle méthode Guardian
PLUG utiliser la nouvelle méthode Guardian
Implémenter le paramètre full_names_visible_to_groups(changement fonctionnel)
CORE Ajouter un nouveau paramètre à la configuration, et vérifier le paramètre dans la méthode Guardian
(1) et (2) se résument à s’assurer que les Guardians sont utilisés de manière plus cohérente et fiable dans tout le code de Discourse.
(3) et (4) consistent à instituer une abstraction plus précise pour contrôler quand les noms complets sont exposés par le backend (en décidant de l’exposition en fonction du contexte que le Guardian représente).
(5) est finalement la partie (relativement triviale) où l’exposition du nom complet est contrôlée par l’appartenance à un groupe.
Merci ! J’ai mis un ingénieur en copie pour qu’il examine la situation. Il semble que vous soyez sur la bonne voie, mais un ingénieur sera en mesure de fournir des commentaires plus éclairés
Je suis désolé, mais je dois rejeter cette PR. Ce changement est trop complexe et difficile à maintenir. Les principales raisons sont :
La portée n’est pas toujours requise et ne devrait pas être imposée ;
Le modifier et le maintenir plus tard dans tous les endroits, comme les plugins, représenterait une quantité de travail énorme ;
PlaceholderGuarian ne résout pas le problème mais ajoute une fausse portée (avec l’intention de corriger plus tard) ;
La plupart du temps, la sérialisation devrait se faire dans le contrôleur, et la portée sera ajoutée automatiquement.
Afficher un nom d’utilisateur ou un nom complet en fonction du groupe est assez délicat. Au lieu d’essayer de le fusionner dans le cœur de Discourse, pouvons-nous commencer par créer un plugin ? Si votre communauté est petite, voici comment cela peut fonctionner :
Définir SiteSetting.enable_names sur false pour utiliser toujours le nom d’utilisateur ;
Définir un point de terminaison qui retournerait une carte de nom d’utilisateur → nom complet pour les utilisateurs TL3 ;
J’ai terminé une PR qui résout le problème initial. L’administrateur pourra toujours voir le nom complet et le modifier. Nous essaierons de la fusionner en début de semaine prochaine
Je pense qu’il y a encore un malentendu/désaccord fondamental sur ce que la configuration enable_names est censée faire, ce qui se résume à cette question :
La configuration enable_names est-elle censée signifier
« Ne pas afficher les noms complets publiquement »,
« Ce site n’utilise pas les noms complets, point final ».
Je pense que certaines personnes sur ce sujet pensent qu’elle fait (1), et d’autres qu’elle fait (2). Mon impression est la seconde, que enable_names décide si le site utilise ou non les noms complets.
Gardez à l’esprit que lorsque enable_names est désactivé :
La boîte de dialogue d’inscription n’offre pas le champ nom complet.
Les utilisateurs ne voient pas le champ nom complet sur leur propre page de préférences de compte ; les utilisateurs ne voient jamais leur propre nom complet nulle part.
Je ne comprends pas le cas d’utilisation d’un site où les administrateurs, et seulement les administrateurs, sont les seules personnes à savoir qu’un champ nom complet existe sur le système. Mon manque d’imagination me rend sceptique quant à l’idée que quelqu’un ici le veuille réellement. Si quelqu’un le veut, s’il vous plaît, éclairez-moi !
(Je pense qu’il y a aussi un malentendu sur ce que ma PR draft essaie d’accomplir, et comment, et pourquoi — mais je voulais d’abord aborder la question « Que fait réellement enable_names ? ».)
Oui, je peux citer de nombreux exemples. Souvent, l’entreprise propriétaire de la communauté a le droit légal (et/ou le besoin) de connaître les noms de ses clients, mais les lois sur la protection de la vie privée lui interdisent de publier ces noms à des tiers. C’est à peu près la même raison pour laquelle utiliser la copie carbone (CC) dans un e-mail de masse est une mauvaise idée et qu’il faut utiliser la copie carbone cachée (BCC).
Eh bien, cela a commencé comme un rapport de bug assez simple où il se comportait mal. Et puis nous avons tous eu une discussion sur ce qu’il était censé faire, ce qui a également causé beaucoup de confusion et de discussions supplémentaires. Ce qui est bien, mais aurait été mieux dans un sujet de type Feature.
C’est le #1. La description du paramètre dit :
Afficher le nom complet de l’utilisateur sur son profil, sa carte utilisateur et ses e-mails. Désactiver pour masquer le nom complet partout.
Le fait que le nom complet soit masqué implique qu’il existe, et que les administrateurs peuvent voir les choses cachées.
Il y a aussi display_name_on_posts, full_name_requirement et display_name_on_email_from.
Si vous voulez le #2, je suppose qu’il serait plus logique de s’appuyer sur full_name_requirement et d’y ajouter une option ‘Jamais’.
(Et oui, je suis d’accord sur le fait que enable_names devrait être appelé différemment, mais renommer les paramètres n’est jamais amusant). Et je suis aussi d’accord sur le fait que
Cette correction restaurera-t-elle la fonction d’origine ? C’est-à-dire que l’administrateur et l’utilisateur peuvent voir leur nom complet ? Il semble que ce changement ait initialement causé beaucoup de problèmes par rapport à la fonction d’origine. Même le modérateur devrait avoir la possibilité de voir le vrai nom via un paramètre, car dans certains cas d’utilisation, cela pourrait être souhaitable/nécessaire.
Après que l’équipe a effectué ce changement, tous les utilisateurs qui avaient saisi leur vrai nom ont vu leur champ devenir vide.
Ce paramètre, à mon avis, aurait dû être séparé en 2 paramètres avec des définitions claires. Avec la nouvelle fonctionnalité pour désactiver les noms, il s’agirait d’un nouveau paramètre pour désactiver les vrais noms.
J’ai la chance d’avoir une petite communauté. Imaginez un site avec des milliers de membres dont le vrai nom a été effacé.
)
)
