So definieren Sie benutzerdefinierte Berechtigungen für Staff, Admins und Moderatoren

Hello!

I want to change user groups permissions, for example:
Admin Group - all permissions
Co Admin - can do anything but cannot open some sections on admin pane

How to do that? Thanks!

That’s not possible by default since admins have unrestricted access to all the sections of the forum. Depending on what kind of permissions you want to revoke, maybe demoting them to moderator can be helpful?

Moderator cannot create a categories and i want that

Mods can create categories if you enable the moderators_create_categories settings in your discourse admin.

4 „Gefällt mir“

Where i find that? I looked through all the categories in the admin panel and did not see anything that I could assign to moderators.
*Is there something like moderators_create_themes?

Go to admin > Settings
Then search for the keyword moderators_create_categories

4 „Gefällt mir“

Is your Discourse up to date?

What you are asking is, "Is there something like ‘moderators can crash the whole site by making a broken theme?’ ". I’m pretty sure that the answer is going to be “No.”

You could install a remote theme hosted in github that a moderator could change, but an admin would still need to pull in the changes.

You do not know who will tinker with the themes, how can you make that statement?
I asked this question because there are no groups with custom rules like it said above.

My point is that if you trust someone enough to change themes then you can make them an admin.

If you would like to allow non-admins to modify themes or otherwise change what a moderator can do you’ll need a custom plugin.

2 „Gefällt mir“

Not in my current scenario. We have UX and Design teams and they are only responsible for that area, so only access to the themes would be necessary.

2 „Gefällt mir“

We have this same use case as well. We have outside contractors (web designers) that we want to grant access to this. An full admin would have access to everything, including private management discussions, which is something not desirable.

It would be nice to have a workflow that allows web designers submit or try changes without full admin access.

4 „Gefällt mir“

Hi @Joaquin_Menchacha

Thank you for your post and reminder on this topic.

We also wish (plan) to refine some of the admin controls in the future.

For example, we are interested in a plugin (someday) which will be configured with variables in the yml container file and will restrict certain admin actions (like downloading the full backup of the site) to only certain users (userids).

This plugin idea is “on my plate” and when I get a chance, I’ll look into it more. So far, I have not even taken the first step of looking at the code and examining the feasibility of this idea.

3 „Gefällt mir“

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.

1 „Gefällt mir“

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.

2 „Gefällt mir“

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.

1 „Gefällt mir“

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

1 „Gefällt mir“

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.

2 „Gefällt mir“

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.

:slight_smile:

2 „Gefällt mir“