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

Para que el diseñador pueda trabajar, he tenido que crear un sitio de copia sin contenido donde él es el administrador, y luego copio temas y componentes manualmente. Sin embargo, no es deseable ya que algunos cambios requieren contenido para poder probarlos.

Nosotros tenemos exactamente esta misma necesidad, ¿alguien ha resuelto esto por casualidad?

[JammyDodger]

No sé si esto es útil en esta situación, pero si solo necesitas algo de contenido, existe la tarea populate de rake:

@nathankershaw

Rellenar un servidor de prueba

Si quieres un servidor de staging, entonces deberías rellenarlo con tus datos reales de tu foro real mediante una Restore. A veces son tus datos particulares los que causan el problema, y probar tu foro con otro conjunto de datos puede darte una falsa sensación de esperanza.

Sin embargo, si lo que quieres es un servidor de prueba para ver cómo es Discourse, quizás quieras comprobar las cosas con datos falsos, y si lo haces, puedes hacer esto:

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

Esto rellenará tu foro con algunos datos falsos para que puedas ver cómo se ven las cosas con los temas y plugins que quieras. Si aún no has iniciado tu foro, esto te dará una idea de cómo se verán las cosas.

[AV_C]

Gracias, desafortunadamente no es realmente útil en este momento.

[pfaffman (Jay Pfaffman)]

@AV_C

Tenemos exactamente la misma necesidad, ¿alguien resolvió esto por casualidad?

Si no confías en que el diseñador vea tus datos, ¿qué solución te imaginarías?
¿Podrías darle solo una clave de API que le permitiera usar el discourse_cli para enviarlo allí y luego deshabilitarla cuando haya terminado, tal vez?

[AV_C]

No hay absolutamente ninguna razón para que un diseñador tenga acceso a 100.000 usuarios, lol. Además, iría en contra de las normas del RGPD. ¿Es posible dar una clave de CLI solo para las actualizaciones de temas?

[pfaffman (Jay Pfaffman)]

¡Disculpe! Creo que tiene razón.

Ahora, a diferencia de cuando se creó este tema (que aparentemente era donde estaba mi cerebro cuando escribí mi respuesta), sí tenemos claves de API granulares. No debería ser muy difícil agregar un nuevo ámbito solo para la gestión de temas.

Podría valer la pena crear un nuevo tema en Feature solicitando un ámbito de clave de API para desarrolladores de temas. Esa parece una buena idea.

[Jagster (Jakke Lehtonen)]

@AV_C

iría contra las normas del RGPD

No, no lo es. Puede ir en contra de las normas de ese sitio, pero estas pueden y deben cambiar.

[Heliosurge (Dan DeMontmorency)]

Sería bueno si @AV_C pudiera publicar una referencia a este requisito. Aunque puedo apreciar enormemente por qué un cliente querría restringir el acceso a la base de usuarios e incluso a categorías privadas debido a una variedad de razones. El administrador completo puede acceder a los correos electrónicos de registro de los miembros y las categorías privadas pueden contener otro contenido sensible dependiendo del caso de uso del cliente.

Creo que @pfaffman tiene una buena idea para garantizar que este tipo de brecha pueda cubrirse a través de una API de administrador restringida. Una vez completado el trabajo de diseño, la clave se puede revocar hasta que sea necesaria.

Esto también encajaría con la idea de Jay de no mostrar a un usuario como administrador en la página Acerca de.