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

Per poter lavorare il designer ho dovuto creare un sito copia senza contenuti dove lui è admin, e poi copio temi e componenti manualmente. Tuttavia non è desiderabile poiché alcune modifiche richiedono contenuti per poter essere provate.

Abbiamo esattamente questa esigenza anche noi, qualcuno per caso ha risolto?

[JammyDodger]

Non so se questo sia utile in questa situazione, ma se hai solo bisogno di alcuni contenuti, c’è il task rake populate:

@nathankershaw

Popolare un server di test

Se desideri un server di staging, dovresti popolarlo con i tuoi dati effettivi dal tuo forum effettivo tramite un Ripristino. A volte sono i tuoi dati specifici a causare il problema e testare il tuo forum con un altro set di dati può darti un senso di falsa speranza.

Se invece desideri un server di test per vedere com’è Discourse, potresti voler dare un’occhiata con alcuni dati fittizi e, se lo fai, puoi fare questo:

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

Questo popolerà il tuo forum con alcuni dati fittizi in modo che tu possa vedere come appaiono le cose con temi e plugin che desideri. Se non hai ancora avviato il tuo forum, questo ti darà un’idea di come appariranno le cose.

[AV_C]

Grazie, purtroppo al momento non è molto utile.

[pfaffman (Jay Pfaffman)]

@AV_C

Abbiamo esattamente la stessa esigenza, qualcuno per caso ha risolto?

Se non ti fidi del designer a vedere i tuoi dati, quale soluzione immagineresti?
Potresti dargli solo una chiave API che gli permetterebbe di usare il discourse_cli per inviare il tema lì e poi disattivarla quando ha finito, forse?

[AV_C]

Non c’è assolutamente alcun motivo per cui un designer debba avere accesso a 100.000 utenti lol. Inoltre, sarebbe contro le regole del GDPR. È possibile fornire una chiave CLI solo per gli aggiornamenti del tema?

[pfaffman (Jay Pfaffman)]

Mi scusi! Penso che abbia ragione.

Ora, a differenza di quando è stato creato questo argomento (che apparentemente era dove si trovava il mio cervello quando ho scritto la mia risposta), abbiamo chiavi API granulari. Non dovrebbe essere troppo difficile aggiungere un nuovo ambito solo per la gestione dei temi.

Potrebbe valere la pena creare un nuovo argomento in Feature chiedendo un ambito di chiave API per sviluppatori di temi. Sembra una buona idea.

[Jagster (Jakke Lehtonen)]

@AV_C

sarebbe contro le regole del GDPR

No, non lo è. Può essere contro le regole di quel sito, ma quelle possono e dovrebbero cambiare.

[Heliosurge (Dan DeMontmorency)]

Sarebbe bello se @AV_C potesse pubblicare un riferimento a questo requisito. Sebbene possa apprezzare molto il motivo per cui un cliente vorrebbe limitare l’accesso alla base utenti e persino alle categorie private per una serie di ragioni. L’amministratore completo può accedere alle email di registrazione dei membri e le categorie private potrebbero contenere altri contenuti sensibili a seconda del caso d’uso del cliente.

Penso che @pfaffman abbia una buona idea per garantire che questo tipo di lacuna possa essere coperta tramite un’API amministrativa ristretta. Una volta completato il lavoro di progettazione, la chiave può essere revocata finché non sarà necessaria.

Ciò si adatterebbe anche all’idea di Jay di non mostrare un utente come amministratore nella pagina Informazioni.