Beachten Sie die Sichtbarkeitseinstellungen aller automatischen Gruppen

[mdoggydog]

(Die Feature-Anfrage der einen Person ist der Fehlerbericht der anderen Person… )

Die Indexseite „Gruppen“ (z. B. /groups oder /g) sollte die Sichtbarkeitseinstellungen der automatischen Gruppen berücksichtigen und sie entsprechend anzeigen. Dies geschieht für die Gruppe „Moderatoren“, aber nicht für andere. Dies liegt an einer fest kodierten Ausnahme in GroupsController.index(), die dazu führt, dass die anderen automatischen Gruppen niemals auf der Indexseite angezeigt werden, wenn sie von Nicht-Mitarbeitern aufgerufen werden, unabhängig von den Sichtbarkeitseinstellungen.

Dieses außergewöhnliche Verhalten ist in mindestens zwei Punkten problematisch:

1. Wenn ein Administrator automatische Gruppen für Nicht-Mitarbeiter indizieren möchte, verhindert dies, dass er dies tut.
2. Die Diskrepanz zwischen der Sichtbarkeitseinstellung und der tatsächlichen Sichtbarkeit ist gefährlich verwirrend. Insbesondere erweckt es den Anschein, dass die Einstellung für automatische Gruppen ignoriert/irrelevant ist (z. B. „Mensch, ich schätze, automatische Gruppen sind immer nur für Mitarbeiter, egal was ich hier einstelle…“), obwohl die Einstellung weiterhin den Zugriff auf bestimmte Gruppenseiten (z. B. /g/trust_level_0) und deren Mitgliederlisten steuert.

Ein Kommentar im relevanten Code besagt, dass dieses außergewöhnliche Verhalten dazu dient, „automatische Gruppen für alle Nicht-Mitarbeiter zu verbergen, um die Seite übersichtlicher zu gestalten“ – aber es gibt keinen Grund, diesen Mechanismus dafür zu verwenden. Ein Administrator, der die Indexseite übersichtlicher gestalten möchte, könnte einfach die Sichtbarkeit automatischer Gruppen nach eigenem Ermessen festlegen, genau wie bei jeder anderen Gruppe.

Ich schlage vor, einfach die 6 Codezeilen aus app/controllers/groups_controller.rb zu entfernen, die dieses Verhalten implementieren.

Wenn es als wichtig erachtet wird, standardmäßig eine „übersichtliche“ Indexseite zu haben für Neuinstallationen von Discourse, dann wäre ein besserer Mechanismus die Standard-Sichtbarkeitseinstellungen für Mitarbeiter für die automatischen Gruppen festzulegen, wenn sie zum ersten Mal vom System erstellt werden. den Standardfilter auf der Indexseite für Nicht-Mitarbeiter auf „nicht automatisch“ zu setzen.

(Die Sichtbarkeitseinstellung ist eine Zugriffskontrolle – der Standardwert sollte sein, was ein sinnvolles Standardzugriffsniveau darstellt, unabhängig davon, wie die Indexseite aussieht.)

Zu Ihrer Information, dieses Thema ist eine Fortsetzung der Diskussion in:

How does visibility of automatic groups work?

I’m a bit confused as to how the visibility of automatic groups works. At this point, I am just talking about the /groups directory. Here is what I am seeing in a pretty fresh install of 2.7.0.beta4: If an user with admin or moderator bits looks at /groups, they see all 8 automatic groups (admins, moderators, staff, trust_level_[0-4]). If a non-admin, non-moderator user (no matter the trust_level) looks at /groups, they see only the moderators group. But, all of these groups have the same, …

[simon]

[quote=“mdoggydog, post:1, topic:280998”]Der Unterschied zwischen der Sichtbarkeitseinstellung und der tatsächlichen Sichtbarkeit ist gefährlich verwirrend.
[/quote]

Als normaler Benutzer bevorzuge ich die übersichtlichere Ansicht, die Vertrauensstufengruppen scheinen für mich nicht relevant zu sein. Aber ich stimme auch zu, dass die Art und Weise, wie die Dinge jetzt funktionieren, seltsam erscheint. Insbesondere angesichts dessen:

[quote=“mdoggydog, post:1, topic:280998”]obwohl die Einstellung weiterhin den Zugriff auf bestimmte Gruppenseiten (z. B. /g/trust_level_0) und deren Mitgliederlisten steuert.
[/quote]

Wenn die Vertrauensstufengruppenseiten nützlich sind, sollte es eine Möglichkeit geben, über die Benutzeroberfläche darauf zuzugreifen, ohne die URL kennen zu müssen.

[quote=“mdoggydog, post:1, topic:280998”]Wenn es wichtig ist, bei Neuinstallationen von Discourse standardmäßig eine „aufgeräumte“ Indexansicht zu verwenden, dann wäre ein besserer Mechanismus, einfach standardmäßig die Sichtbarkeitseinstellungen für die automatischen Gruppen auf „nur für Mitarbeiter“ zu setzen, wenn sie vom System zum ersten Mal erstellt werden.
[/quote]

Das ergibt für mich Sinn. Es muss vielleicht darauf geachtet werden, dass die Einschränkung der Sichtbarkeit einer Vertrauensstufengruppe nichts kaputt macht. Derzeit ist es nicht möglich, öffentliche Veranstaltungen zu erstellen, wenn die TL0-Gruppe für den Benutzer, der die Veranstaltung erstellt, nicht sichtbar ist. Ich bin mir nicht sicher, ob es andere ähnliche Fälle gibt.

[RGJ (Richard - Communiteq)]

Wäre das nicht einfach zu lösen durch

• „Automatische Gruppen“ im Filter-Dropdown für Nicht-Administratoren verfügbar machen?
• Den Standardfilter (sowohl für Administratoren als auch für normale Benutzer) so einstellen, dass automatische Gruppen ausgeschlossen werden
• Sicherstellen, dass /g/trust_level_0?asc=true die gleiche Autorisierungslogik wie /g?type=automatic verwendet (derzeit funktioniert ersteres, während letzteres „Keine sichtbaren Gruppen vorhanden.“ anzeigt)

Zusätzliche Anfrage: Wenn auf /g über /admin zugegriffen wird, verschwinden plötzlich die Admin-Menüleisten. Ich finde das störend. Wie wäre es, diese Menüleisten auf dieser Seite hinzuzufügen, wenn /g von einem Administrator aufgerufen wird?

[Moin]

@RGJ

Zusätzliche Anfrage: Wenn über /admin auf /g zugegriffen wird, verschwinden plötzlich die Admin-Menüleisten

Es gibt ein #ux-Thema Groups Tab in Admin Inconsistent With Other Tabs, das dies diskutiert

[mdoggydog]

@simon

Das ergibt für mich Sinn. Es muss vielleicht darauf geachtet werden, dass die Einschränkung der Sichtbarkeit einer Vertrauensstufengruppe nichts kaputt macht.

Ja, “duh”, wie man so schön sagt… Ich habe meinen ursprünglichen Vorschlag überarbeitet, um dies widerzuspiegeln. “Sichtbarkeit” ist eine Zugriffskontrolle und sollte als solche behandelt werden (z. B. sollte die Benutzeroberfläche den Zustand der Kontrolle transparent widerspiegeln, anstatt dass die Kontrolle verdreht wird, um das Aussehen der Benutzeroberfläche abzustimmen).

@RGJ

Wäre das also nicht einfach zu lösen durch

• die Verfügbarkeit von „Automatischen Gruppen“ im Filter-Dropdown für Nicht-Admins?
• den Standardfilter (sowohl für Admins als auch für normale Benutzer) so einzustellen, dass die automatischen Gruppen ausgeschlossen werden?

In der Tat! Mir war nicht aufgefallen, dass “automatisch” im Filter-Dropdown für Nicht-Mitarbeiter nicht verfügbar ist. (Es wird durch denselben 6-Zeilen-Codeblock ausgeblendet, der auch die automatischen Gruppen ausblendet – das Entfernen dieses Codes würde das also auch beheben.)

Der Backend-Code definiert zwar bereits einen “non_automatic”-Filter, der aber anscheinend niemandem (weder Mitarbeitern noch anderen) im Filter-Dropdown angeboten wird.

[tobiaseigen]

@mdoggydog

• Wenn ein Administrator möchte, dass automatische Gruppen für Nicht-Mitarbeiter indiziert werden, hindert ihn das daran.

Wenn Sie „automatische Gruppen für Nicht-Mitarbeiter indizieren“ sagen, meinen Sie dann, dass Nicht-Mitarbeiter den Filter für automatische Gruppen aufrufen und diese sehen können?

@mdoggydog

Die Diskrepanz zwischen der Sichtbarkeitseinstellung und der tatsächlichen Sichtbarkeit ist gefährlich verwirrend.

Das ist eine berechtigte Sorge. Wir versuchen, die Admin-Erfahrung einfacher und konsistenter zu gestalten, und dies scheint ein Bereich zu sein, der Leute stolpern lassen kann. Ich habe keine anderen Beschwerden über diesen speziellen Fall gehört, aber ich sehe den Wert darin, ihn zu beheben, damit das Verhalten konsistent ist.

@mdoggydog

Ich schlage vor, einfach die 6 Codezeilen aus app/controllers/groups_controller.rb zu entfernen, die dieses Verhalten implementieren.

Wenn es als wichtig erachtet wird, bei neuen Installationen von Discourse standardmäßig eine „entrümpelte“ Indexansicht zu haben, dann wäre ein besserer Mechanismus, einfach standardmäßig die Sichtbarkeitseinstellungen nur für Mitarbeiter für die automatischen Gruppen zu verwenden, wenn sie vom System erstellt werden.

Diese beiden Punkte scheinen sinnvoll zu sein. Gibt es jedoch unbeabsichtigte Folgen, wenn die Sichtbarkeitseinstellungen für automatische Gruppen geändert werden, bevor wir dies tun?

@RGJ

Wäre das also nicht leicht zu lösen durch

• „Automatische Gruppen“ im Filter-Dropdown für Nicht-Admins verfügbar machen?
• Den Standardfilter (sowohl für Admins als auch für normale Benutzer) so einstellen, dass die automatischen Gruppen ausgeschlossen werden
• Sicherstellen, dass /g/trust_level_0?asc=true die gleiche Autorisierungslogik wie /g?type=automatic verwendet (derzeit funktioniert ersteres, während letzteres sagt „Es gibt keine sichtbaren Gruppen.“

Das sieht gut aus als To-Do-Liste. Danke, dass Sie es so formuliert haben.

[mdoggydog]

@tobiaseigen

@mdoggydog

• If an admin wants to index automatic groups for non-staff users, this prevents them from doing that.

When you say “index automatic groups for non-staff users”, do you mean allow non-staff users to be able to access the automatic groups filter and see them?

In that quoted text, I specifically mean “show automatic groups on the /g index page when viewed by non-staff users”. Regardless of the filter setting, the automatic groups (except for “Moderators”) are currently not allowed to be listed on the /g index page for non-staff users.

In a later post (the one preceding this one), I additionally advocate for providing the “Automatic Groups” option in the filter dropdown for all users, not just stafff users. I don’t think there is a good reason to hide it from non-staff users. (Note that no matter what is presented in the dropdown menu, the filter is still available to any user who can type the correct keyword into the URL bar.)

@tobiaseigen

@mdoggydog

I suggest simply removing the 6 lines of code from app/controllers/groups_controller.rb that implements this behavior.

If it is considered important to default to a “de-cluttered” index for new installations of Discourse, then a better mechanism would be to simply default to staff-only visibility settings for the automatic groups when they are first created by the system.

These two items seem to make sense. However, before we do this are there any unintended consequences of changing the visibility settings for automatic groups?

Please note that I edited my suggestion for default de-cluttering prior to your post; you have quoted the original version. The revised/current text from my first post is (with the strikeouts removed for brevity):

@mdoggydog

If it is considered that important to default to a “de-cluttered” index, then a better mechanism would be to set the default filter on the index page to “non-automatic” for non-staff users.

(The visibility setting is an access control — the default value should be whatever constitutes a sane default level of access, regardless of what the index page looks like.)

[tobiaseigen]

Derzeit sieht die Benutzerliste auf einer neuen Website wie folgt aus.

Um die Anfrage in meinen eigenen Worten zusammenzufassen: Die Gruppenübersicht unter /g soll wie folgt geändert werden:

1. Zeigen Sie auch den Filter für automatische Gruppen für Mitglieder an.
2. Zeigen Sie alle automatischen Gruppen für Mitglieder an, wenn der Filter ausgewählt ist.
3. Schließen Sie automatische Gruppen aus der Standardansicht unter /g aus.

Ich bin der Meinung, dass (3) für jeden gelten sollte, nicht nur für Mitglieder. Ein Ziel, das wir verfolgen, ist es, Administratoren und Moderatoren eine möglichst ähnliche Erfahrung wie Mitgliedern zu bieten, um Verwirrung zu vermeiden.

Durch diese Änderung machen wir die Existenz von automatischen Gruppen, auf die Mitglieder Zugriff haben, aber derzeit die URL kennen müssen, in der Benutzeroberfläche explizit.

Für Administratoren:

Für Mitglieder:

[mdoggydog]

@tobiaseigen

Um es mit meinen eigenen Worten zusammenzufassen: Die Anfrage besteht darin, das Gruppenverzeichnis unter /g wie folgt zu ändern:

1. Zeigen Sie auch den Filter für automatische Gruppen für Mitglieder an
2. Zeigen Sie alle automatischen Gruppen für Mitglieder an, wenn der Filter ausgewählt ist
3. Schließen Sie automatische Gruppen aus der Standardansicht unter /g aus

Ich würde es neu formulieren, was die zu treffenden Änderungen betrifft, und die Prioritäten etwas verschieben:
A. Hören Sie auf, automatische Gruppen für Nicht-Mitarbeiter aus dem Index zu entfernen
B. Hören Sie auf, den Filter „Automatische Gruppen“ für Nicht-Mitarbeiter aus dem Dropdown-Menü zu entfernen
C. Bieten Sie allen Benutzern den Filter „Nicht-automatische Gruppen“ im Dropdown-Menü an
D. Aktivieren Sie den Filter „Nicht-automatische Gruppen“ standardmäßig unter /g

Meine Formulierung von C und D im Vergleich zu 3 ist beabsichtigt: Ich denke, die Benutzeroberfläche sollte sehr transparent darüber sein, welche Filterung aktiv ist. Wenn kein Filter ausgewählt ist, sollte die Benutzeroberfläche eine ungefilterte Ansicht anzeigen, d. h. jede Gruppe anzeigen, die für den Benutzer sichtbar/zugänglich ist.

Man könnte 3 so interpretieren, dass „wenn kein Filter ausgewählt ist, dann wird leise der non_automatic-Filter verwendet“, aber ich denke, das wäre immer noch verwirrend. Wenn kein Filter ausgewählt ist, dann sollte einfach kein Filter angewendet werden. Umgekehrt, wenn ein Filter angewendet wird, sollte er benannt und für den Benutzer sichtbar gemacht werden.

Wenn man tiefer in die Details eintaucht: Ein Teil des Problems bei der Auswahl des Filters ergibt sich aus der Art und Weise, wie der Hinweis „Nach Gruppentyp filtern“ in die Bezeichnung für das Menüelement ohne ausgewählten Filter gequetscht wurde. Ich denke, es wäre letztendlich klarer, wenn das Element ohne ausgewählten Filter „Alle Gruppen“ heißen würde. Dann fügen Sie ein zusätzliches Element „Nicht-automatische Gruppen“ hinzu, und Sie können jedes der Elemente zum Standard machen. Auf diese Weise ist (a) klar, wann der Benutzer eine gefilterte Ansicht erhält, und (b) klar, wie man zu einer ungefilterten Ansicht wechselt.

Wenn es nach mir ginge, würde ich die Menüpunkte des Filters wie folgt bezeichnen:

• Alle Gruppen
• Gruppen, denen ich angehöre (weil Meine Gruppen mehrdeutig ist.)
• Gruppen, die mir gehören
• Öffentliche Gruppen
• Private Gruppen (weil Geschlossen wie „abgeschaltet“ oder „nicht mehr in Gebrauch“ klingt.)
• Automatische Gruppen
• Nicht-automatische Gruppen

Und ich würde den Hinweistext in der Textbox von „Alle Gruppen“ zu „Nach Gruppennamen filtern“ ändern.

Und… ich würde die Reihenfolge des Dropdown-Menüs und der Textbox vertauschen!

[tobiaseigen]

Vielen Dank, dass Sie mir beim Nachdenken geholfen haben. Ich glaube nicht, dass wir im Moment größere Änderungen am UX der Gruppenliste vornehmen werden, aber mir gefällt die Idee, die Gruppenliste zumindest für alle gleich zu machen.

@mdoggydog

Wenn es nach mir ginge, würde ich die Filtermenüpunkte wie folgt bezeichnen:

• Alle Gruppen
• Gruppen, denen ich angehöre (weil Meine Gruppen mehrdeutig ist.)
• Gruppen, die mir gehören
• Öffentliche Gruppen
• Private Gruppen (weil Geschlossen wie „abgeschaltet“ oder „nicht mehr in Gebrauch“ klingt.)
• Automatische Gruppen
• Nicht-automatische Gruppen

Das sind alles gute Vorschläge, außer dass ich “Automatisch” und “Nicht-automatisch” klobig und technisch klingende Namen finde, die nicht so aussagekräftig sind. Da es bei automatischen Gruppen um Privilegien geht, die Menschen erlangt oder gewährt wurden, können wir vielleicht eine Bezeichnung finden, die das widerspiegelt?

[almereyda (jon r)]

Ich bin gerade mit demselben Gedanken hierher gekommen, dass es besser wäre, die Standardansicht auf das zu haben, was heutzutage als „Öffentliche + Geschlossene Gruppen“ bezeichnet wird, und somit eine solche Option einzuführen. Und die Mehrdeutigkeiten rund um „Meine Gruppen“, die als das verstanden werden könnten, was „Gruppe, die ich besitze“ tatsächlich bedeutet, und „Geschlossene Gruppen“, die so klingen könnten, als wären sie nicht mehr aktiv, zu beseitigen, erscheint ebenfalls vernünftig.

@mdoggydog

• Automatische Gruppen
• Nicht-Automatische Gruppen

Diese klingen stark nach:

• Systemgruppen
• Benutzergruppen, „Öffentliche & Private Gruppen“ oder einfach Gruppen

Vielleicht könnte die Reihenfolge der in diesem Filterelement angebotenen Gruppen konfiguriert werden, wobei der erste Eintrag immer die Standardansicht ist, damit wir diese auswählen können. Andernfalls wäre es eine weitere Frage, eine geeignete Standardreihenfolge zu finden, die für alle funktioniert, und eine dieser Ansichten als Standard festzulegen.

Außerdem könnten wir „Automatischen/Systemgruppen“ menschenlesbare Namen-Aliase geben, zum Beispiel bevorzugen einige Sprachen Großbuchstaben am Anfang, wie beim Feld „Vollständiger Name“ in regulären Gruppen, und ihnen optional sinnvolle Standardbeschreibungen zur Verfügung stellen, damit diese weniger „technisch“ erscheinen, wenn ein Website-Administrator sie nicht über sein Verwaltungsmenü in ihrer Beschreibung erläutern möchte.

Vielleicht könnte es auch eine Art visuelle Unterscheidung zwischen „Automatischen“ und „Nicht-Automatischen“ Gruppen geben, wie ein Symbol, oder ihre Felder werden hellgrau schattiert oder so ähnlich.

[tobiaseigen]

Ich mag Systemgruppen!

[simon]

„Automatisch“ klingt, als würde es sich darauf beziehen, wie ein Implementierungsdetail – Benutzer werden automatisch zu den Gruppen hinzugefügt. Ich glaube nicht, dass das aus der Sicht eines normalen Benutzers viel Sinn ergibt. Es ist auch nicht ganz korrekt. Benutzer werden nicht automatisch zu den Staff-Gruppen hinzugefügt. Wahrscheinlich wäre der genaueste Name für die automatischen Gruppen „vorgefüllte Gruppen“, aber das ist ein schrecklicher Name.

„System“-Gruppen klingt in Ordnung, aber was ist mit der Unterteilung der automatischen Gruppen in „Vertrauensstufen“ und „Staff“? Der Filter für den Gruppentyp wäre so etwas wie:

• Meine Gruppen
• Gruppen, die mir gehören
• Öffentliche Gruppen
• Geschlossene Gruppen
• Vertrauensstufen
• Staff

Bei Bedarf könnte es eine Website-Einstellung wie trust level groups public geben, die bestimmt, ob die Vertrauensstufen-Gruppen auf der Gruppenseite sichtbar sind oder nicht.

[tobiaseigen]

Es ist eine gute Idee, die Website-Mitarbeiter separat aufzuführen. Die Leute würden es vielleicht sogar zu schätzen wissen, hier eine Liste von Moderatoren und Administratoren zu finden. Andernfalls müssten sie wissen, dass sie zu /about gehen müssen.

[mdoggydog]

Nochmals ein Wort dazu… zählt mich zu den Discourse-Benutzern/Administratoren, die keinen Filter „alles außer System-/Gruppen“ wirklich benötigen. Die Anwesenheit dieser Gruppen scheint einfach nicht so störend zu sein.

Wie auch immer, meine Priorität ist es, einen echten ungefilterten „Alle Gruppen“-Filter verfügbar zu machen, und meine eigene Präferenz ist es, es einfach zu halten und diesen zum Standard für die Seite /groups zu machen.