Hallo!
Ich möchte die Berechtigungen für Benutzergruppen ändern, zum Beispiel:
Admin-Gruppe – alle Berechtigungen
Co-Admin – kann alles tun, darf aber bestimmte Bereiche im Admin-Bereich nicht öffnen
Wie geht das? Danke!
Das ist standardmäßig nicht möglich, da Administratoren uneingeschränkten Zugriff auf alle Bereiche des Forums haben. Je nachdem, welche Berechtigungen Sie entziehen möchten, könnte es hilfreich sein, sie zu Moderatoren herabzustufen?
Moderatoren können keine Kategorien erstellen, und ich möchte das.
Mods können Kategorien erstellen, wenn Sie die Einstellung moderators_create_categories in Ihrem Discourse-Admin aktivieren.
Wo finde ich das? Ich habe alle Kategorien im Admin-Bereich durchsucht und nichts gefunden, das ich Moderatoren zuweisen könnte.
*Gibt es etwas wie moderators_create_themes?
Gehe zu Admin > Einstellungen
Suche dann nach dem Schlüsselwort moderators_create_categories
Ist dein Discourse auf dem neuesten Stand?
Das, was du fragst, ist: „Gibt es etwas wie ‚Moderatoren können die gesamte Seite durch ein fehlerhaftes Theme zum Absturz bringen?’
Du weißt nicht, wer mit den Themes herumspielen wird. Wie kannst du eine solche Aussage treffen?
Ich habe diese Frage gestellt, weil es keine Gruppen mit benutzerdefinierten Regeln gibt, wie oben erwähnt.
Mein Punkt ist: Wenn du jemandem genug vertraust, um Themes zu ändern, kannst du ihn zum Administrator machen.
Wenn du Nicht-Administratoren erlauben möchtest, Themes zu bearbeiten oder sonst zu bestimmen, was ein Moderator tun kann, benötigst du ein benutzerdefiniertes Plugin.
Nicht in meinem aktuellen Szenario. Wir haben UX- und Designteams, die nur für diesen Bereich zuständig sind, sodass nur der Zugriff auf die Themes erforderlich wäre.
Wir haben diesen Anwendungsfall ebenfalls. Wir arbeiten mit externen Auftragnehmern (Webdesignern) zusammen, denen wir Zugang dazu gewähren möchten. Ein vollständiger Administrator hätte Zugriff auf alles, einschließlich privater Managementdiskussionen, was nicht wünschenswert ist.
Es wäre wünschenswert, einen Workflow zu haben, der es Webdesignern ermöglicht, Änderungen einzureichen oder zu testen, ohne vollen Admin-Zugriff zu benötigen.
Hallo @Joaquin_Menchacha,
vielen Dank für deinen Beitrag und die Erinnerung an dieses Thema.
Wir wünschen uns ebenfalls (und planen), einige der Admin-Steuerungen in Zukunft zu verfeinern.
Zum Beispiel sind wir an einem Plugin interessiert (irgendwann), das mit Variablen in der yml-Container-Datei konfiguriert wird und bestimmte Admin-Aktionen (wie das Herunterladen eines vollständigen Backups der Website) nur bestimmten Benutzern (User-IDs) erlaubt.
Diese Plugin-Idee liegt mir „auf dem Herzen“, und wenn ich die Gelegenheit habe, werde ich mich genauer damit beschäftigen. Bisher habe ich noch nicht einmal den ersten Schritt unternommen, den Code zu prüfen und die Machbarkeit dieser Idee zu untersuchen.
Hat hier jemand eine Lösung gefunden?
Ich habe denselben Anwendungsfall, bei dem ich einigen meiner Mitarbeiter Zugriff auf das Theme und auf Hauswerbung gewähren möchte.
Die einfache Lösung besteht darin, Leuten zu vertrauen und sie zum Administrator oder Moderator zu machen. Wenn du ihnen keine vollständige Kontrolle anvertraust, sie aber dennoch zusätzlichen Zugriff gewähren möchtest, benötigst du ein Plugin.
Es ist nicht so, dass ich ihnen nicht vertraue. Aber im Hinblick auf unser Bedrohungsmodell schafft es eine zusätzliche Angriffsfläche. Was ist, wenn der spezifische Benutzer aufgrund mangelnder Sicherheit auf seiner Seite kompromittiert wird? Es sind viele Variablen im Spiel.
Wir werden dann die Plugin-Option untersuchen.
Zustimmung: Discourse benötigt zusätzliche Steuerungsmöglichkeiten zur Anpassung. Wie andere bereits erwähnt haben, könnte dies bedeuten, externe Auftragnehmer einzustellen, um Funktionen auf höherer Ebene zu nutzen, während gleichzeitig die Informationen der Mitglieder geschützt bleiben.
Die Gruppenmoderation ist gut, aber manchmal wünscht man sich einige erweiterte Funktionen eines vollständigen Moderators, ohne jedoch alle Funktionen zu benötigen.
Ein Plugin könnte tatsächlich hilfreich sein. Aber genau wie der Merge-User-Plugin in den Kern integriert wurde, sollten auch stärkere, anpassbare Moderator-/Admin-Funktionen eingeführt werden, um mehr Arten von Mitarbeiterrollen zu ermöglichen.
Ich stimme den anderen hier zu, dass das Zugriffssteuerungsmodell durch eine zusätzliche Ebene der RBAC-Granularität (rollenbasierte Zugriffskontrolle) verbessert werden könnte, die festlegt, auf was staff und admin zugreifen können (für bestimmte Funktionen, nicht für alle).
Zum Beispiel möchte eine Website vielleicht mehr Admins hinzufügen, bevorzugt aber, diesen ein kleineres Set an RBAC-Rechten zu gewähren; etwa die Möglichkeit, das vollständige Website-Backup herunterzuladen oder auf bestimmte Protokolle von Staff-Aktionen zuzugreifen, zu gewähren oder nicht. Darüber hinaus möchte eine Website sicherstellen, dass einige Mitarbeiter nicht über RBAC-Berechtigungen verfügen, um die Aktionen von Admins oder Entwicklern einzusehen, oder nur bestimmte Aktionen, die als „privater
Hallo @jrgong,
Das ist über ein Plugin nicht schwer umzusetzen, wie du wahrscheinlich gut weißt.
Grundsätzlich könntest du eine Liste von Mitarbeitern (per E-Mail, Benutzername usw.) als globale Einstellung erstellen, ähnlich wie Discourse Entwickler per E-Mail-Adresse definiert.
Anschließend könntest du diese GlobalSetting in einigen Patches verwenden, um die beiden Anwendungsfälle zu ermöglichen, die dich interessieren.
Dein erster Anwendungsfall: Themes als Mitarbeiter anpassen, ist meiner Meinung nach relativ einfach durch einen Core-Monkey-Patch umzusetzen.
Bei deinem zweiten Anwendungsfall könntest du mit wenig Aufwand dieses Plugin forken und die Zugriffsbeschränkung der Route in diesem Plugin (sowie alle anderen erforderlichen Änderungen) neu gestalten:
Da die Beschränkung für das Anzeigen-Plugin fest im Plugin integriert ist, ist es eine gute Idee, diesen Code tatsächlich zu ändern, um deinen „zugelassenen" Mitarbeitern den Zugriff auf die Teile dieses Plugins zu ermöglichen, die du zulassen möchtest, basierend auf deiner eigenen RBAC.
Mit anderen Worten: Beide Anforderungen, die du hast, sind umsetzbar, wenn du bereit bist, den Code zu schreiben; oder natürlich kannst du einen der fähigen Discourse-Plugin-Entwickler-Profis im Marketplace um Hilfe bitten.
Danke @neounix, ich schätze den Input sehr! Ich werde einen Entwickler beauftragen, das umzusetzen.
Edit: Gibt es keine andere Möglichkeit, als das Plugin zu forken?
Und wie sieht es mit dem Zugriff auf das Babble-Chat-Plugin aus? Würde das auch einen Fork erfordern?
Wir sprechen über Software.
Es gibt immer viele Wege, Dinge zu tun.
Ich habe dir meine Empfehlungen gegeben.
