How to define custom permissions for staff, admins, moderators

[merefield (Robert)]

Sorry old post but why don’t you set up your theme as a repo in GitHub? Permission your design and UX team to have access to update the Theme in GitHub.

In Discourse you can now set Themes to auto update upon rebuild.

Your admins will now only need to rebuild to bring in any changes made by the Design and UX team and the latter will not need access to admin at all.

[neounix (Dark Matter)]

Just a short note:

When coding matters of access control, in general, these RBAC checks should be performed on the server side.

RBAC code in client-side Javascript can be manipulated by the client.

This means that when defining core RBAC permissions for staff, admins and moderators, this should be done (generally speaking) in Rails, not in Javascript.

OBTW, this is also how Discourse does RBAC now, using what Discourse calls “guardian”, a Ruby class called class Guardian, here:

https://github.com/discourse/discourse/blob/master/lib/guardian.rb

If a developer is going to add RBAC checks in Javascript code by calling the Discourse API, keep in mind that this code can be compromised because code which runs in the browser can be manipulated.

My recommendation is to make sure all core RBAC code is performed on the server side and do not try to short cut this in client-side Javascript.

[codinghorror (Jeff Atwood)]

There is also trust level 4 and category moderators, in discourse 2.5 and beyond.

[nicolailang]

@dgateles

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

I have a similar use case, in that I run a small non-profit community where one of our users is maintaining the themes and design.

I do not wish to give anyone beside me and my co-owner access to private user data (e-mail addresses etc.), but I do have 4 moderators.

In order for the designer to work, I’ve had to create a copy site with no content where he is the admin, and I then copy themes and components manually. However it is not desirable since some changes requires content in order to proof.

[codinghorror (Jeff Atwood)]

Why not add some content to the staging / testing site? That’d be the typical recommendation.

[pfaffman (Jay Pfaffman)]

So let the developer develop on the staging site, and push the themes to github. But you’ll still need to upgrade them yourself. You might contrive to do the upgrade with the API and somehow make the developer be able to trigger it.

I’m working of a tool that might be able to help with that.

[AV_C]

@Nicolailang

Damit der Designer arbeiten kann, musste ich eine Kopie der Website ohne Inhalt erstellen, bei der er Administrator ist, und dann kopiere ich Themes und Komponenten manuell. Dies ist jedoch nicht wünschenswert, da einige Änderungen Inhalt erfordern, um sie zu beweisen.

Wir haben genau diese Anforderung auch, hat dies zufällig jemand gelöst?

[JammyDodger]

Ich weiß nicht, ob das in dieser Situation nützlich ist, aber wenn Sie nur einige Inhalte benötigen, gibt es die populate Rake-Aufgabe:

@nathankershaw

Seeding a Test Server

Wenn Sie einen Staging-Server haben möchten, sollten Sie ihn mit Ihren tatsächlichen Daten von Ihrem tatsächlichen Forum über eine Restore bevölkern. Manchmal sind es Ihre spezifischen Daten, die das Problem verursachen, und das Testen Ihres Forums mit einem anderen Datensatz kann Ihnen ein Gefühl falscher Hoffnung geben.
Wenn Sie jedoch einen Testserver haben möchten, um zu sehen, wie Discourse ist, sollten Sie die Dinge mit gefälschten Daten überprüfen, und wenn Sie dies tun, können Sie Folgendes tun:

./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

Dies wird Ihr Forum mit gefälschten Daten bevölkern, damit Sie sehen können, wie die Dinge mit den von Ihnen gewünschten Themes und Plugins aussehen. Wenn Sie Ihr Forum noch nicht gestartet haben, erhalten Sie hier eine Vorstellung davon, wie die Dinge wahrscheinlich aussehen werden.

[AV_C]

Danke, leider ist es im Moment nicht wirklich nützlich.

[pfaffman (Jay Pfaffman)]

@AV_C

Wir haben genau die gleiche Anforderung, hat das zufällig jemand gelöst?

Wenn Sie dem Designer nicht vertrauen, dass er Ihre Daten sieht, welche Lösung würden Sie sich vorstellen?
Könnten Sie ihm nur einen API-Schlüssel geben, mit dem er die discourse_cli verwenden kann, um das Thema dort hochzuladen, und ihn dann deaktivieren, wenn er fertig ist, vielleicht?

[AV_C]

Es gibt absolut keinen Grund, warum ein Designer Zugriff auf 100.000 Benutzer haben sollte, lol. Außerdem würde dies gegen die DSGVO-Regeln verstoßen. Ist es möglich, einen CLI-Schlüssel nur für Theme-Updates zu geben?

[pfaffman (Jay Pfaffman)]

Entschuldigen Sie vielmals! Ich glaube, Sie haben Recht.

Im Gegensatz zu dem Zeitpunkt, als dieses Thema erstellt wurde (was offenbar der Zustand meines Gehirns war, als ich meine Antwort schrieb), haben wir jetzt granulare API-Schlüssel. Es sollte nicht allzu schwer sein, einen neuen Geltungsbereich nur für die Verwaltung von Themes hinzuzufügen.

Es könnte sich lohnen, ein neues Thema in Feature zu erstellen und nach einem Theme-Entwickler-API-Schlüssel-Geltungsbereich zu fragen. Das scheint eine gute Idee zu sein.

[Jagster (Jakke Lehtonen)]

@AV_C

Es wäre gegen die DSGVO-Regeln

Nein, das ist es nicht. Es kann gegen die Regeln dieser Website verstoßen, aber diese können und sollten sich ändern.

[Heliosurge (Dan DeMontmorency)]

Es wäre gut, wenn @AV_C vielleicht einen Verweis auf diese Anforderung posten könnte. Obwohl ich gut verstehen kann, warum ein Kunde den Zugriff auf die Benutzerbasis und sogar auf private Kategorien aus verschiedenen Gründen einschränken möchte. Vollständige Administratoren können die Anmelde-E-Mails der Mitglieder einsehen und private Kategorien können andere sensible Inhalte enthalten, je nach Anwendungsfall des Kunden.

Ich denke, @pfaffman hat eine gute Idee, um sicherzustellen, dass diese Art von Lücke durch eine eingeschränkte Admin-API abgedeckt werden kann. Sobald die Designerarbeit abgeschlossen ist, kann der Schlüssel widerrufen werden, bis er benötigt wird.

Dies würde auch zu Jays Idee passen, einen Benutzer nicht als Administrator auf der Über-uns-Seite anzuzeigen.