Das ist das Ergebnis, wenn wir versuchen, eine Unterkategorie für Administratoren (das gleiche Problem gilt für Moderatoren) innerhalb der Kategorie „Staff
Sie müssen sicherstellen, dass die von Ihnen erstellten Unterkategorien nur für Mitarbeiter verfügbar sind. Sie haben versucht, eine Kategorie zu erstellen, die für alle zugänglich war, haben dabei jedoch die Berechtigungen nicht beachtet, weshalb Sie dies nicht für zutreffend halten.
Das habe ich auch gedacht, daher habe ich meine Nachricht gelöscht. Lies dir aber noch einmal die Fehlermeldung durch:
„Jede Gruppe, der der Zugriff auf eine Unterkategorie erlaubt ist, muss auch Zugriff auf die übergeordnete Kategorie haben. Die folgenden Gruppen haben Zugriff auf eine der Unterkategorien, aber keinen Zugriff auf die übergeordnete Kategorie: Moderatoren.“
Ich habe es versucht und auf dasselbe Problem gestoßen.
Ich versuche, eine Unterkategorie zu erstellen, bei der die Sicherheit auf „Moderatoren: Anzeigen/Beitragen/Erstellen“ eingestellt ist, aber ich erhalte dieselbe Fehlermeldung, obwohl Moderatoren angeblich in „Mitarbeiter“ enthalten sein sollten und die Sicherheit der übergeordneten Kategorie auf „Mitarbeiter: Lesen/Beitragen/Erstellen“ eingestellt ist.
Klingt nach einem Fehler, aber warum nicht die Kategorie ‘Sonne’ für das Personal und nicht nur für Moderatoren lesbar machen?
Ich denke, das liegt daran, dass die Sicherheit über Gruppen und nicht über Berechtigungen festgelegt wird.
Ein Moderator gehört sowohl zur Staff- als auch zur Moderator-Gruppe.
Was würde aber passieren, wenn es eine Staff-Kategorie und eine Moderator-Unterkategorie gäbe, für jemanden, der nur der Moderator-Gruppe angehört? Er könnte auf die Unterkategorie zugreifen, aber nicht auf die übergeordnete Kategorie – und Discourse erlaubt das nicht.
Theoretisch müsste man, wenn man eine für Moderatoren zugängliche Unterkategorie haben möchte, die Berechtigung „Moderatoren: sehen/beiträgen/erstellen“ zur Sicherheit der übergeordneten Kategorie hinzufügen. Das ist jedoch bei der standardmäßigen Staff-Unterkategorie nicht möglich.
Außerdem wäre das sinnlos, da „Staff“ sowohl Moderatoren als auch Administratoren umfasst, und Administratoren Zugriff auf alle Kategorien haben.
Jemand müsste das überprüfen. Aber meiner Vermutung nach könnte ein Nutzer möglicherweise der Moderatorengruppe hinzugefügt werden, ohne die Moderator-Rolle zu besitzen.
Bei Mitarbeitern sind hingegen Moderator- oder Admin-Rechte erforderlich.
Ja. Aber genau das haben wir gemacht. Wir haben die Berechtigungen für „alle
Das ist falsch. Mods können auf die Kategorie für Mitarbeiter zugreifen. Daher sollte eine Unterkategorie für Mods (oder Admins) von Discourse erlaubt sein (oder es sollte sein). Die Regel besagt, dass jede Gruppe, die auf eine Unterkategorie zugreifen kann, auch auf die übergeordnete Kategorie zugreifen muss.
Aber es wäre keineswegs sinnlos, eine Unterkategorie nur für Admins zu haben, da Mods nicht alles sehen können, was Admins sehen.
Lies meine Nachricht genauer: Wie das System aufgebaut ist, funktioniert es ordnungsgemäß, und der Fehler, den du festgestellt hast, ist normal. Der Zugriff auf das Forum hängt ausschließlich von Gruppen ab.
Die von Discourse automatisch erstellte Standard-Kategorie für Mitarbeiter ist nur für die Gruppe Staff verfügbar.
Wenn du eine Unterkategorie für die Gruppe Moderatoren erstellen möchtest, wird das nicht funktionieren, da die übergeordnete Kategorie nur für die Gruppe Staff und nicht für die Gruppe Moderatoren verfügbar ist.
Der einzige Grund, warum Moderatoren Zugriff auf die übergeordnete Kategorie haben, ist, dass sie auch zur Gruppe Staff gehören.
Du kannst dennoch eine Unterkategorie namens „Moderation“ erstellen und die Sicherheitseinstellung auf „Mitarbeiter können lesen/beitragen/antworten“ festlegen – das wird funktionieren.
Das wäre es sehr wohl, und du kannst problemlos eine Kategorie oder Unterkategorie erstellen, die nur für die Gruppe Administratoren verfügbar ist.
Um es klarzustellen: Ich bin der Ansicht, dass dies tatsächlich der Grund für das Problem ist. Ursprünglich wollte ich dies als Erklärung erwähnen, habe mich dann aber entschieden, ohne weitere Ausführungen zu posten.
In diesem Fall handelt es sich jedoch um einen jener tückischen Bugs, bei denen die von Ihnen entwickelten Regeln nicht den Gründen entsprechen, die zu ihrer Entstehung geführt haben. Es ist völlig klar, dass Moderatoren ebenso wie Administratoren zum Team gehören, und dieser Grund würde es nahelegen, dass sie Unterkategorien innerhalb von „Team“ erstellen können.
Tatsächlich war es vor einigen Jahren möglich, Unterkategorien im Bereich „Team“ ausschließlich für Administratoren oder nur für Moderatoren zu erstellen; dies war eindeutig korrekt.
Warum sollte es sinnlos sein, eine Unterkategorie nur für Administratoren zu haben?
Nicht im Bereich „Team“. Schauen Sie sich den Screenshot oben an.
Ich meinte, es wäre nicht sinnlos, wie du sagtest. 
Ja, du hast recht.
Wenn du diese Unterkategorien erstellen möchtest, solltest du eine übergeordnete Kategorie „News Personal“ erstellen, bei der die Sicherheitseinstellungen so gesetzt sind, dass Administratoren, Personal und Moderatoren lesen/beiträgen/erstellen können, denke ich.
Warum nicht einfach eine neue Kategorie erstellen, wie erwähnt? Das Personal ist eine spezialisierte Gruppe.
Ich kann Benutzer mehreren Gruppen hinzufügen. Nur weil einige Benutzer zur Gruppe B gehören und möglicherweise auch Teil der Gruppe A sind, bedeutet das nicht, dass der Zugriff der Gruppe A auf eine Kategorie automatisch auch der Gruppe B Zugang gewährt. Die Vertrauensstufen-Kategorienberechtigungen funktionieren jedoch auf einem Mindestniveau.
Ich weiß es nicht genau, aber ich vermute, du kannst die Personalberechtigungen wahrscheinlich so bearbeiten, dass die Moderator-Gruppe direkten Zugriff erhält.
Es gibt in Discourse keine hierarchischen Berechtigungen. „Staff“ ist eine spezielle Sammlung aus Admins und Moderatoren. Unterkategorien können keine Gruppen angeben, die nicht in der übergeordneten Kategorie vorhanden sind, und die „Staff“-Gruppe hat feste ACLs. Wie in der Kategorie „Staff“ vermerkt:
Warnung: Diese Kategorie ist eine vorkonfigurierte Kategorie, und die Sicherheitseinstellungen können nicht bearbeitet werden. Wenn du diese Kategorie nicht verwenden möchtest, lösche sie anstatt sie für einen anderen Zweck umzudeuten.
Das ist kein Fehler, du hast einfach einen Anwendungsfall, der nicht zur Standard-„Staff“-Kategorie passt. Es ist nichts falsch daran, etwas anderes tun zu wollen, aber es wäre falsch zu behaupten, dass dies ein Fehler sei, nur weil man eine eingebaute Kategorie nicht für einen anderen Zweck verwenden kann.
Es ist ziemlich klar, dass du sie nicht so verwenden möchtest, wie sie ist. Nichts hindert dich daran, eine neue übergeordnete Kategorie zu erstellen, die für Administratoren und Moderatoren zugänglich ist, und darunter separate Unterkategorien für jeden Bereich anzulegen.
Dies ist ein äußerst kleiner Fehler im Warnsystem für Kategorienberechtigungen, da es nicht erkennt, dass staff gleich admins + moderators ist. Das ist keine 12 Beiträge lange Diskussion wert.
Als Workaround kannst du admins und moderators explizit als erlaubte Gruppen zur übergeordneten Kategorie hinzufügen. Beachte jedoch, dass Admins weiterhin Zugriff auf die Unterkategorie moderators haben.
Ja. Aber Moderatoren haben keinen Zugriff auf die Administratoren-Unterkategorien.
Ja, im Allgemeinen, aber das ist in der Kategorie „Mitarbeiter“ (Staff) nicht möglich, die automatisch erstellt wird und bei der die Berechtigungen nicht geändert werden können – genau darum ging es in der Frage. Da (a) die Kategorie „Mitarbeiter“ bei jeder Installation automatisch angelegt wird, (b) es aus Gründen der Benutzerfreundlichkeit wichtig ist, die Anzahl der Kategorien zu begrenzen, und (c) die Kategorie „Mitarbeiter“ früher ordnungsgemäß funktionierte, halte ich diese Anforderung nicht für unangemessen.
Mein Vorschlag ist eine einfache Lösung. Derzeit werden beim automatischen Erstellen der Kategorie „Mitarbeiter“ folgende Berechtigungen festgelegt (die nicht geändert werden können):
Mitarbeiter können erstellen/antworten/sehen
Stattdessen sollte Discourse beim automatischen Erstellen der Kategorie „Mitarbeiter“ folgende Berechtigungen festlegen:
Mitarbeiter können erstellen/antworten/sehen
Administratoren können erstellen/antworten/sehen
Moderatoren können erstellen/antworten/sehen
Mit dieser einfachen Korrektur wäre dieser Fehler behoben, wir müssten keine zusätzlichen und unnötigen Kategorien erstellen, und die Kategorie „Mitarbeiter“ würde wieder so funktionieren wie in der Vergangenheit.
Ich finde, deine Punkte sind verkehrt herum. Eine speziell für deine Zwecke erstellte Kategorie zu erstellen, ist bei weitem einfacher, als eine integrierte Kategorie zu ändern – insbesondere, wenn Tausende anderer Installationen bereits mit den bestehenden Berechtigungen arbeiten.
Tatsächlich wirst du, wenn du meine Lösung sorgfältig liest, erkennen, dass sie rückwärtskompatibel ist und dafür sorgt, dass vorherige Installationen weiterhin so funktionieren wie zuvor.
Das hat jedoch nichts mit Abwärtskompatibilität zu tun. In diesem Thema bist du die einzige Person, die eine Änderung fordert. Dein Vorschlag erfordert immer noch Entwicklungszeit, immer noch Tests und immer noch Wartung. Tausende von Installationen, die mit der bestehenden Konfiguration funktionieren, bedeuten auch, dass es Tausende von Admin- und Moderationsteams gibt, die mit der aktuellen Einstellung einverstanden sind.
Dieses Thema ist Monate alt. Du hättest die korrekte Methode dazu bereits im April umsetzen können. Warum erwartest du, dass CDCK eine Änderung an ihrer Software finanziert, die seit sieben Jahren so funktioniert, nur für eine einzelne Site? Warum sollte jemand etwas tun, wenn du nicht bereit bist, die einfachste Änderung an deiner eigenen Konfiguration vorzunehmen? Deine Weigerung, den Empfehlungen zu folgen, ermutigt niemanden zum Handeln.
Es gibt nichts Besonderes an der Kategorie „Mitarbeiter“, wie vor Monaten vorgeschlagen, könntest du eine andere Kategorie mit den entsprechenden Berechtigungen erstellen. Problem gelöst.
Es ist für dich bei weitem einfacher, eine kleine Änderung in deiner Community umzusetzen, als irgendeine der oben genannten Optionen.
Es ist nicht die richtige Lösung – aber ich habe sie im April umgesetzt. Wir warten normalerweise nicht darauf, dass Fehler behoben oder Funktionen implementiert werden, bevor wir unsere eigenen Angelegenheiten regeln.
Ja, ja und nein. Ich habe viele Jahre als Softwareentwickler und Manager gearbeitet und weiß genau, was es bedeutet, einen Fehler zu beheben. Diese Korrektur würde ein paar Minuten Entwicklungszeit, ein paar Stunden Testzeit erfordern und keine höhere Wartungsanforderung stellen als die aktuelle Version.
Dein Argument würde bedeuten, dass es absolut keinen Sinn macht, etwas Neues zu entwickeln. Es gibt Tausende von Teams, die Discourse so verwenden, wie es ist – warum sollte man auch nur eine weitere Stunde in die Entwicklung investieren? Bitte nutzen wir Logik, wenn wir argumentieren.
Das war eine unnütz unhöfliche Unterstellung, die angesichts meiner obigen Kommentare offensichtlich unbegründet ist.
Tatsächlich liegst du falsch. Es hat lange Zeit anders und besser funktioniert. Hier ist ein Beispiel für ein bestehendes, gehostetes Discourse-System, das 4–5 Jahre alt ist und eine native Staff-Kategorie mit Untergruppen für Moderatoren besitzt:
Der Punkt hat nichts mit meinem System zu tun. Ich brauche die Änderung nicht, damit es funktioniert. Der Punkt ist, dass jedes Discourse-System mit einer Staff-Kategorie geliefert wird, die in ihren Fähigkeiten unterlegen ist gegenüber dem, was sie sein könnte und was sie war. Wenn Discourse sich die Mühe macht, eine Staff-Kategorie automatisch zu erstellen, warum dann nicht eine gut durchdachte und saubere Lösung implementieren? Ich mache einen Vorschlag, der einfach und leicht umzusetzen ist und Fähigkeiten zurückbringt, die für uns, die wir mit mehreren Staff-Kategorien arbeiten, nützlich sind. Das Team ist frei, meinen Vorschlag zu prüfen – oder auch nicht.
Warnung: Diese Kategorie ist eine vorkonfigurierte Kategorie, und die Sicherheitseinstellungen können nicht bearbeitet werden. Wenn Sie diese Kategorie nicht verwenden möchten, löschen Sie sie, anstatt sie umzuwidmen.
Soll ich einfach die Mitarbeiterkategorie neu erstellen und die Themen in die neue Kategorie verschieben?