Beim Hinzufügen von Gruppen zu einer Kategorie können die Optionen anonymous_users und logged_in_users ausgewählt werden, sie funktionieren jedoch nicht.
2 „Gefällt mir“
Erfordert dies nicht, dass die Beta-Funktion „Granulare Berechtigungen für anonyme und angemeldete Gruppen“ aktiviert ist?
1 „Gefällt mir“
@martin hast du dazu eine Idee?
1 „Gefällt mir“
Danke für den Bericht, ich werde mir das ansehen 
Aus deiner Antwort im anderen Thema
Je mehr ich darüber nachdenke, desto mehr mache ich mir Sorgen.
Was passiert, wenn ich nur anonymous_users zu einer Kategorie hinzufüge und nicht logged_in_users?
Was passiert, wenn ich anonymous_users hinzufüge, während mein Forum login_required (Anmeldung erforderlich) ist?
Außerdem ist die aktuelle technische Implementierung so, dass bei Kategorieberechtigungen auf everyone gesetzt, einfach kein Eintrag in category_groups existiert und read_restricted auf false gesetzt ist.
Das ist sehr einfach und direkt: Wenn keine Berechtigungen gesetzt sind, werden die Berechtigungen durch die globalen Forenberechtigungen (die login_required-Einstellung) bestimmt und es gelten keine weiteren Einschränkungen.
Eine solche Änderung würde also eine enorme Menge an Komplexität hinzufügen und seltsame Kombinationen wären möglich (man könnte anonymous users und staff kombinieren 
)
Mein Vorschlag wäre:
anonymous_usersals Option für Kategorieberechtigungen ganz entferneneveryoneundlogged_in_usersbeibehaltentrust_level_0als Option entfernen, da eslogged_in_usersentspricht
oder alternativ, aber vielleicht weniger klar für weniger erfahrene Administratoren:
anonymous_usersundlogged_in_usersals Option für Kategorieberechtigungen entferneneveryone(und TL0) beibehalten
In allen Fällen: everyone beibehalten. Und du brauchst auch keine Migration 
4 „Gefällt mir“
Danke für deine Gedanken, deshalb wollte ich anfangs bei dieser Änderung für alle nicht zu sehr in Kategorieberechtigungen einsteigen 
Ich denke, viel von dem, was du hier sagst, könnte einfach unmöglich gemacht werden. Ich arbeite bereits an einigen vorläufigen Systemen hier mit ACLs und einer schöneren Berechtigungs-UI für unser Kanban-Plugin, das wir entwickeln. Hier ist ein Beispiel. Wir beabsichtigen, die Kategorieberechtigungen irgendwann so zu ändern, dass sie dies verwenden:
Es sind mehrere Regeln im Spiel, wie z. B. dass es unmöglich ist, anonymen Benutzern Manager-Berechtigungen für ein Kanban-Brett zu geben, und so weiter. Es unterstützt sogar obligatorische Berechtigungen, wie z. B. dass Admins immer ein Brett verwalten können.
Wir würden es so einrichten, dass du keine anonymen Benutzer hinzufügen kannst, wenn das Forum eine Anmeldung erfordert.
Wieder eine Validierung/Einschränkung, die wir hinzufügen können.
Wir könnten auch Validierungen/Warnungen für solche Dinge hinzufügen.
Das ist genau das, was ich vermeiden möchte: diese Art von impliziten Berechtigungen, die überall in Discourse vorhanden sind, anstatt für eine Kategorie, die öffentlich/nicht lesebeschränkt ist, immer explizit angemeldete Benutzer + anonyme Benutzer einzurichten.
Wie auch immer, für jetzt will ich nicht zu tief in dieses Thema einsteigen. Es ist noch ein Stück Weg, bis ich mich mit Kategorien befasse. Aber ich stimme zu, dass der ursprüngliche Beitrag ein Fehler ist, der in der Zwischenzeit behoben werden muss, also werde ich das trotzdem tun.
1 „Gefällt mir“
Angesichts dieses anderen Problems würde ich persönlich von einer solchen Logik abraten. Was passiert, wenn ich ein Forum auf „Anmeldung erforderlich“ umstelle, während sich bereits anonyme Benutzer in der Berechtigungsliste befinden? Und umgekehrt? Das wird ein Albtraum und für Administratoren undurchsichtig sein.
Ich bin sehr skeptisch gegenüber einer solchen Komplexität.
2 „Gefällt mir“
Wieder einmal viele gute Punkte. Es gibt viel zu bedenken, und diese Thematik ist knifflig. Ich werde auf jeden Fall die Administratorerfahrung im Hinterkopf behalten, wenn ich Änderungen an den Kategorien vornehme. Hier gibt es viel Historie, und ich möchte niemanden überraschen. Nichts davon wird schnell umgesetzt; es wird lange dauern, bis ich alle verschiedenen Szenarien sorgfältig durchgearbeitet habe, wenn ich an diesem Projekt arbeite.
1 „Gefällt mir“
Ich frage mich, warum die Tatsache, dass man Einstellungen für anonyme Nutzer konfigurieren kann, nicht jedoch für angemeldete Nutzer, im Kontext von Kategorieberechtigungen ein Problem darstellt, im Kontext von Berechtigungen, die über Site-/Plugin-/Theme-Einstellungen konfiguriert werden, jedoch nicht. Ein einfaches Beispiel: Es ist nun möglich, den Styleguide für anonymous_users verfügbar zu machen, ohne logged_in_users hinzuzufügen. Macht das mehr Sinn, als einer Kategorie für anonyme Nutzer, aber nicht für angemeldete Nutzer, sichtbar zu sein?
1 „Gefällt mir“
Nein, das ergibt keinen Sinn, es ist wirklich nur ein weiterer Randfall, den man abdecken muss… Ich werde anonymous_users zu disallowed_groups für dieses Plugin hinzufügen. Außerdem bin ich stark davon überzeugt, dass es nicht viele Websites in der Wildnis gibt, die dieses Plugin aktiviert haben, also mache ich mir im Moment keine großen Sorgen, dass dies falsch konfiguriert wird.
Ich denke, so würde ich das im Allgemeinen bei diesen Arten von Einstellungen handhaben. Wir können auch mandatory_values nutzen, um sicherzustellen, dass bestimmte Gruppen immer ausgewählt sind, sodass man nicht an einigen Stellen nur anonymous_users hat. Oder wir nutzen Einstellungsgültigkeitsprüfungen, um zu sagen, dass man anonymous_users nicht ohne mindestens eine authentifizierte Benutzergruppe auswählen kann, und so weiter.
Ich verstehe nicht, warum das nötig ist. Was ist daran falsch, wenn es eine Option ist?
Funktioniert das nur für Site-Einstellungen oder auch für Theme-Komponenten?
Funktionierte bisher noch nicht für Theme-Komponenten, aber es könnte. Wiederum laufen wir hier wirklich etwas zu schnell vorneweg.