Das Deaktivieren von "Namen aktivieren" lässt Administratoren seltsam handeln

Fehler
29

Ich habe im Grunde den Anwendungsfall in Restrict exposure of full name to certain groups dargelegt. Wir nutzen Discourse, um die Diskussion über lokale öffentliche Schulen zu erleichtern; die Zielnutzerschaft sind hauptsächlich Eltern und andere lokale Gemeindemitglieder. Wir möchten eine Balance finden:

  • Einerseits soll die Seite anonym durchsuchbar sein (damit Suchmaschinen sie indizieren können, damit sie auch für Nicht-Mitglieder zugänglich ist, damit sie prinzipiell offen/transparent ist, …)
  • Andererseits möchten wir unnötigerweise persönlich identifizierbare Informationen für Crawler und anonyme Besucher vermeiden – wir möchten, dass Leute ihre Namen innerhalb der Community teilen können und möchten die Zurückhaltung vieler Leute dabei adressieren.

Ursprünglich sah es so aus, als ob das Deaktivieren von „Anzeigename in Beiträgen“ und das Aktivieren von „Benutzerprofile vor der Öffentlichkeit verbergen“ ausreichen würde, um Namenslecks an anonyme Benutzer zu verhindern – aber dann stellten wir fest, dass dies nicht der Fall ist. (Und wir haben es den Leuten bereits über TOS und FAQ versprochen. :lying_face:)

Die Verweigerung des Zugriffs auf vollständige Namen nur für anonyme Benutzer würde das Problem lösen. Da es jedoch genauso einfach ist, den Zugriff an die Gruppenzugehörigkeit zu koppeln, dachte ich, ich könnte es genauso gut tun – was die Möglichkeit eröffnet, auf unserer Seite den Zugriff auf >=TL1 zu beschränken, was noch besser ist. (Derzeit benötigen wir eine Einladung zur Anmeldung, aber wir möchten das abschaffen.)

Bei der Untersuchung dieses Problems/Themas habe ich andere Erwähnungen gleicher oder ähnlicher Anfragen gesehen, z. B. „wir möchten nur, dass diese oder jene Gruppe Namen sehen kann“ … das würde also auch diese Fälle abdecken.

Eine Frage an Sie (die Sie vielleicht sogar als Produktfrage betrachten!):

  • Bedeutet die Einstellung enable_names „Vollständige Namen nicht für Benutzer anzeigen“ oder eher „Diese Seite verwendet generell keine vollständigen Namen“?

Ich habe das Gefühl (aus dem Code selbst und aus Themen/Problemen wie diesem), dass es hier an Klarheit mangelt – und einige Leute haben es so und andere anders verstanden.

4 „Gefällt mir“
30

Gibt es hier Fortschritte? Es scheint, dass dies die am einfachsten zu erreichende Funktion mit der größten positiven Auswirkung ist.

4 „Gefällt mir“
31

Einverstanden. Administratoren sollten Zugriff auf den vollständigen Namen haben können, ohne den Schalter ein- und ausschalten zu müssen. Es gibt besonders wichtige Gründe (zumindest für unser Forum), echte Namen zu verbergen.

3 „Gefällt mir“
32

Ich wäre sicherlich dankbar, wenn Fortschritte in diesem Thema gemacht werden könnten. Wir haben einen unmittelbaren und anhaltenden Bedarf dafür.

1 „Gefällt mir“
33

Vielen Dank an alle, die zu diesem Thread beigetragen haben. Ich möchte nur respektvoll fragen, ob dieses Problem in einer der nächsten Versionen behoben wird – oder zumindest als bekannte Regression anerkannt wird.

Das Deaktivieren von “Namen aktivieren” beeinträchtigt derzeit wichtige Admin-Funktionen auf eine Weise, die unbeabsichtigt erscheint, und die mangelnde Klarheit darüber, ob dies beabsichtigt ist oder ein Fehler, erschwert uns die Planung. Für diejenigen von uns, die Produktionsseiten betreiben, auf denen Benutzernamen gegenüber vollständigen Namen bevorzugt werden, führt diese Einschränkung zu echten Problemen und unerwartetem Verhalten.

Ich verstehe, dass Prioritäten abgewogen werden müssen, aber es wäre unglaublich hilfreich, ein Update vom Team zu erhalten, ob dies auf dem Radar ist. Vielen Dank im Voraus für alle Einblicke, die Sie geben können.

1 „Gefällt mir“
34

Hallo, @tobiaseigen, gibt es technisches Feedback dazu? (Es ist 3 Monate her – aber ich war auch mit anderen Dingen beschäftigt und habe den Überblick verloren, also kann ich mich nicht beschweren.)

Ich könnte diese Woche Pull Request(s) einreichen, um die Konversation konkreter zu gestalten – aber ich habe Bedenken, dass sie unbeachtet bleiben, und ich könnte auch etwas Feedback zu einigen Aspekten meines Ansatzes gebrauchen.

Bearbeiten: Um es klarzustellen, ich spreche von Pull Requests für eine Implementierung von Restrict exposure of full name to certain groups - #2 by mdoggydog (was es ermöglicht, Namen aktivieren zu aktivieren und gleichzeitig zu steuern, wer die vollständigen Namen sehen darf).

2 „Gefällt mir“
35

@RGJ @chrismalone und @mdoggydog Vielen Dank für Ihren Beitrag hier. Wir benötigen diesen Fix weiterhin und sind dankbar für alle, die an dem Problem arbeiten.

2 „Gefällt mir“
36

Ehrlich gesagt, bin ich überrascht, dass dem nicht mehr Aufmerksamkeit geschenkt wurde. Ich verstehe es aus irgendeinem Grund, dass man zögert, eine PR zu erstellen, ohne zu wissen, ob sie überprüft wird und möglicherweise implementiert wird.

Obwohl eine PR, wie ich mir vorstelle, vielleicht ein Plugin werden könnte, aber das beschränkt diese Option mehr auf selbst gehostete (self hosted) Lösungen.

39

@mdoggydog Es sieht so aus, als ob Ihre Lösung hier darin besteht, die Einstellung enable names durch eine zu ersetzen, die eine Liste von Gruppen akzeptiert, und die Namen der Mitglieder sind nur für diese Gruppen sichtbar.

Beachten Sie, dass dies weiterhin die Einstellung display name on posts (und alle anderen ähnlichen, die möglicherweise vorhanden sind) berücksichtigen müsste, sodass selbst zugelassene Gruppen den Namen in Beiträgen nicht sehen, wenn diese Einstellung deaktiviert ist.

Zusätzlich gibt es einige andere Dinge, die wir hier als Folgeerscheinungen beheben/ändern müssen:

  1. Namen sollten in der Admin-Ansicht eines Benutzerprofils immer sichtbar sein. Dies ist unabhängig von allen Einstellungen der Fall.
  2. Namen sollten nur in E-Mails angezeigt werden, wenn sich der Benutzer in einer zulässigen Gruppe befindet.

Das Obige sollte die aktuellen Probleme beheben und diese Funktion flexibler und nützlicher machen.

Klingt das nach dem, was Sie hier vorschlagen? Wenn ja, würden wir uns auf jeden Fall freuen, uns jeden PR anzusehen, den Sie mit diesem Update einreichen.

40

Der von mir geschriebene Code entfernt die Einstellung enable names nicht[1], sondern ergänzt sie:

  1. Eine Einstellung full_names_visible_to_groups hinzufügen (die admins und moderators als obligatorische Werte enthält).
  2. Eine Methode can_see_full_names? zu Guardian hinzufügen, die ein „und“ von enable_names und der Gruppenmitgliedschaft in full_names_visible_to_groups durchführt.
  3. Diese neue Methode an allen geeigneten Stellen verwenden, an denen ein vollständiger Name vom Server angezeigt/ausgegeben wird.

1 und 2 waren einfach. 3 ist komplizierter, und ich bin auf einige Schwierigkeiten gestoßen, bei denen ich mir nicht sicher war, wie ich sie lösen sollte, ohne Rat/Anleitung zu erhalten. Ich muss meinen Code und meine Notizen gründlich überprüfen. (Es ist mehr als 2 Monate her, seit ich mich damit beschäftigt habe. :see_no_evil_monkey:)

(Wenn ich mich richtig erinnere, sind display name on posts und ähnliche Einstellungen clientseitige Einstellungen, die die Darstellung von Daten beeinflussen, die vom Server empfangen werden. Mit anderen Worten, eine Einschränkung zusätzlich zu dem, was der Server ausgibt.)

Ich glaube, (1) ist erledigt, wenn enable_names wahr ist, was wahrscheinlich die meisten Leute wollen werden, sobald die neue gruppenbezogene Einstellung verfügbar ist.[2]

Ich glaube, ich bin auf (2) gestoßen und habe es größtenteils behandelt.[3]

Ich erinnere mich an einige andere Fälle, in denen vollständige Namen durchsickern.[4]

Auf jeden Fall werde ich meine Notizen überprüfen und versuchen, diese Woche PRs einzureichen, und dabei die offenen Fragen/losen Enden aufdecken.

  1. …aus einer Reihe von Gründen, unter anderem: (a) Ich war mir nicht sicher, was die tatsächliche Absicht der Einstellung ist (siehe meine Frage in einem früheren Beitrag oben) und (b) sie beizubehalten, bietet einen sichereren inkrementellen Upgrade-Pfad. ↩︎

  2. …wenn man davon ausgeht, dass enable_names = false bedeutet: „Diese Website verwendet vollständige Namen in keiner Weise.“ ↩︎

  3. z. B. wenn eine Einladungs-E-Mail an eine Adresse gesendet wird (die offensichtlich keinem Benutzer zugeordnet ist, sonst bräuchte sie keine Einladung), enthält die E-Mail den vollständigen Namen des Einladenden oder nicht? ↩︎

  4. z. B. oneboxer.rb schreibt beim Oneboxing eines lokalen Benutzers den vollständigen Namen in den gekochten Beitragstext, was ihn für jeden und jeden für immer sichtbar macht. ↩︎

4 „Gefällt mir“
41

Das klingt super! Könntest du deinen PR hier verlinken? Dann lasse ich einen Techniker ihn genauer ansehen.

6 „Gefällt mir“
42

Der erste (von 2 oder 3) PR ist hier:

Dieser PR ist eine Voraussetzung für die nachfolgenden, um sicherzustellen, dass Guardian-Instanzen tatsächlich von einem Serializer zum nächsten übergeben werden. Details finden Sie im PR/Commit-Nachricht. Die Diskussion über diesen PR kann beginnen, während ich den nächsten vorbereite.

Mein Mini-GitHub-Konto-Abenteuer

…nun, es war da, bis ich die URL in das Bearbeitungsfeld hier eingegeben habe …und dann wurde mein gesamtes Konto plötzlich gesperrt. :face_with_monocle: :weary_cat: :face_with_symbols_on_mouth: :crying_cat_face: :alien:

Ich habe eine Wiederherstellungsanfrage gestellt und werde diese aktualisieren, sobald ich eine Aktualisierung habe.

13 Stunden später erhielt ich eine E-Mail, in der im Grunde stand: „Manchmal passiert das; alles wieder gut.“ Sehr kafkaesk. Mein Konto war von der Website verschwunden – bis zu dem Punkt, dass Beiträge, die ich vor Jahren in Issues/PRs gemacht hatte, verschwunden waren und mysteriöse einseitige Gespräche hinterließen, wobei ein paar geisterhafte Blockzitate die einzige Beweis dafür waren, dass jemand anderes (ich) dort gewesen war.

Dies scheint erschreckend überzogen zu sein, nicht nur für das gesperrte Konto, sondern auch für all die Projekte, deren Geschichte stillschweigend gestrichen wurde.

3 „Gefällt mir“
43

Ich stelle fest, dass dies auch die Koordination von Änderungen in den Discourse-Plugin-Repos beinhalten wird — was eine Kette von PRs (Pull Requests) in einer Art Inside-Out-Reihenfolge bedeutet, um sicherzustellen, dass Tests immer bestehen (und natürlich, dass main immer funktionsfähig ist).

Ich stelle mir die Sequenz wie folgt vor (wobei CORE “PR in discourse/discourse” und PLUG “PR(s) in offiziellen Plugin-Repos” bedeutet):

  1. Erzwingen der Serializer-Scope-Weiterleitung (keine funktionale Änderung erwartet)
    a. CORE Implementierung der Serializer-Scope-Prüfung, standardmäßig deaktiviert
    b. PLUG Fehlerbehebungen für die Scope-Weiterleitung
    c. CORE Fehlerbehebungen für die Scope-Weiterleitung und standardmäßige Aktivierung der Scope-Prüfung
  2. Präventives Bereitstellen von Guardians (Ersetzen von Platzhaltern) an den für Phase 4 notwendigen Stellen (keine funktionale Änderung erwartet)
    • CORE Platzhalter-Fixes
    • PLUG Platzhalter-Fixes
  3. Implementierung von einfachem Guardian#can_see_full_names?, das nur von enable_names abhängt (keine funktionale Änderung erwartet)
    • CORE Hinzufügen einer Methode zu Guardian
  4. Verwenden von can_see_full_names? überall dort, wo der vollständige Name ausgegeben wird (Ersetzen der bloßen Verwendung von enable_names, falls erforderlich) (möglicherweise funktionale Änderung)
    • CORE Verwendung der neuen Guardian-Methode
    • PLUG Verwendung der neuen Guardian-Methode
  5. Implementierung der Einstellung full_names_visible_to_groups (funktionale Änderung)
    • CORE Hinzufügen einer neuen Einstellung zur Konfiguration und Überprüfen der Einstellung in der Guardian-Methode

(1) und (2) laufen darauf hinaus, sicherzustellen, dass Guardians konsistenter und zuverlässiger in der gesamten Discourse-Codebasis verwendet werden.

(3) und (4) dienen dazu, eine präzisere Abstraktion für die Steuerung der Anzeige von vollständigen Namen durch das Backend einzuführen (Entscheidung über die Anzeige in Abhängigkeit von dem jeweiligen Kontext, den der Guardian repräsentiert).

(5) ist schließlich der (relativ triviale) Teil, in dem die Anzeige vollständiger Namen durch die Gruppenmitgliedschaft gesteuert wird.

3 „Gefällt mir“
45

Danke! Ich habe einen Ingenieur hinzugezogen, der sich das ansehen wird. Es scheint, als wären Sie hier auf dem richtigen Weg, aber ein Ingenieur wird fundierteres Feedback geben können :slight_smile:

4 „Gefällt mir“
48

@hugh danke, dass du dies den richtigen Leuten zur Förderung vorgelegt hast. Wir hoffen schon seit einiger Zeit darauf.

1 „Gefällt mir“
49

Es tut mir leid, aber ich muss diesen PR ablehnen. Diese Änderung ist zu komplex und schwer zu warten. Die Hauptgründe dafür sind:

  • Der Geltungsbereich (Scope) ist nicht immer erforderlich und sollte nicht erzwungen werden.
  • Die Änderung und spätere Wartung an allen Stellen, wie z. B. in Plugins, wäre ein enormer Arbeitsaufwand.
  • PlaceholderGuarian löst das Problem nicht, sondern fügt einen gefälschten Geltungsbereich hinzu (mit der Absicht, ihn später zu beheben).
  • In den meisten Fällen sollte die Serialisierung im Controller erfolgen, und der Geltungsbereich wird automatisch hinzugefügt.

Die Anzeige eines Benutzernamens oder vollständigen Namens basierend auf der Gruppe ist ziemlich knifflig. Anstatt zu versuchen, dies in den Discourse-Kern zu integrieren, können wir nicht damit beginnen, ein Plugin zu erstellen? Wenn Ihre Community klein ist, kann dies so funktionieren:

2 „Gefällt mir“
50

Ich habe gerade einen PR abgeschlossen, der das ursprüngliche Problem löst. Administratoren können immer den vollständigen Namen sehen und ihn bearbeiten. Wir werden versuchen, ihn Anfang nächster Woche zu mergen :crossed_fingers:

3 „Gefällt mir“
51

[Zitat=“kris.kotlarek, Beitrag:50, Thema:291912”]
Ich habe gerade einen PR abgeschlossen, der das ursprüngliche Problem löst. Der Admin kann immer den vollständigen Namen sehen und ihn bearbeiten.
[/Zitat]

Ich denke, es gibt immer noch ein grundlegendes Missverständnis/Uneinigkeit darüber, was die Einstellung enable_names eigentlich bewirken soll, was sich auf folgende Frage reduziert:

  • Soll die Einstellung enable_names bedeuten
    1. „Keine vollständigen Namen öffentlich anzeigen.“,
    2. „Diese Seite verwendet grundsätzlich keine vollständigen Namen.“

Ich denke, einige Leute in diesem Thema denken, dass es (1) bedeutet, und andere denken, dass es (2) bedeutet. Mein Eindruck ist Letzteres, dass enable_names entscheidet, ob die Seite überhaupt vollständige Namen verwendet oder nicht.

Denken Sie daran, wenn enable_names deaktiviert ist:

  • Der Anmeldedialog bietet kein Feld für den vollständigen Namen.
  • Benutzer sehen das Feld für den vollständigen Namen nicht auf ihrer eigenen Seite mit den Kontoeinstellungen; Benutzer sehen ihren eigenen vollständigen Namen nirgendwo.

Ich verstehe den Anwendungsfall für eine Seite nicht, auf der Administratoren, und nur Administratoren, die einzigen Personen sind, die überhaupt wissen, dass ein Feld für den vollständigen Namen im System vorhanden ist. Mein Mangel an Vorstellungskraft lässt mich bezweifeln, dass irgendjemand hier das tatsächlich will. Wenn das jemand möchte, bitte klären Sie mich auf!

(Ich denke, es gibt auch einige Missverständnisse darüber, was mein PR-Entwurf zu erreichen versucht und wie und warum — aber ich wollte zuerst die Frage “Was macht enable_names eigentlich?” beantworten.)

2 „Gefällt mir“
52

Ja, ich kann zahlreiche Beispiele nennen. Oft hat das Unternehmen, dem die Community gehört, das Recht (und/oder die Notwendigkeit), die Namen seiner Kunden zu kennen, aber Datenschutzgesetze verbieten es ihm, diese Namen an Dritte weiterzugeben. Ziemlich dasselbe, warum die Verwendung von CC in einer Massen-E-Mail ein No-Go ist und man stattdessen BCC verwenden sollte.

Nun, das begann als ein ziemlich einfacher Fehlerbericht, bei dem es einfach falsch funktionierte. Und dann haben wir uns alle über das unterhalten, was es tun sollte, was auch zu viel Verwirrung und zusätzlicher Diskussion führte. Was in Ordnung ist, aber besser in einem #feature-Thema aufgehoben gewesen wäre.

Es ist #1. Die Beschreibung für die Einstellung lautet:

Zeigt den vollständigen Namen des Benutzers auf seinem Profil, seiner Benutzerkarte und in E-Mails an. Deaktivieren, um den vollständigen Namen überall zu verbergen.

Die Tatsache, dass der vollständige Name verborgen ist, impliziert, dass er existiert, und Administratoren können versteckte Dinge sehen.

Es gibt auch display_name_on_posts, full_name_requirement und display_name_on_email_from.

Wenn Sie #2 wollen, wäre es wahrscheinlich sinnvoller, auf full_name_requirement aufzubauen und dort eine Option ‘Niemals’ hinzuzufügen.

(Und ja, ich stimme zu, dass enable_names anders genannt werden sollte, aber das Umbenennen von Einstellungen ist nie einfach). Und ich stimme auch zu, dass

seltsam ist.

1 „Gefällt mir“
53

Wird diese Korrektur die ursprüngliche Funktion wiederherstellen? D.h. Admin und Benutzer können ihren vollständigen Namen sehen? Es scheint, dass diese Änderung anfangs viele Probleme im Vergleich zur ursprünglichen Funktion verursacht hat. Selbst ein vollwertiger Moderator sollte die Möglichkeit haben, den echten Namen über eine Einstellung zu sehen, da dies in einigen Fällen gewünscht/benötigt werden könnte.

Nachdem das Team diese Änderung vorgenommen hat, wurden bei allen Benutzern, die einen echten Namen eingegeben hatten, die Felder leer.

Diese Einstellung hätte meiner Meinung nach in 2 Einstellungen mit klaren Definitionen getrennt werden sollen. Mit der neueren Funktion zum Deaktivieren von Namen als neue Einstellung zum Ausschalten von echten Namen.

Ich habe Glück, dass ich eine kleine Community habe. Stellen Sie sich eine Website mit Tausenden von Mitgliedern vor, deren echte Namen leer sind.