Lo siento, es un post antiguo, pero ¿por qué no configuras tu tema como un repositorio en GitHub? Otorga permisos a tu equipo de diseño y UX para que tengan acceso y puedan actualizar el tema en GitHub.
En Discourse, ahora puedes configurar los temas para que se actualicen automáticamente al reconstruir.
Tus administradores solo necesitarán reconstruir para incorporar los cambios realizados por el equipo de diseño y UX, y este último no necesitará acceso de administrador en absoluto.
Solo una nota breve:
Al programar aspectos de control de acceso, en general, estas verificaciones de RBAC deben realizarse en el lado del servidor.
El código de RBAC en JavaScript del lado del cliente puede ser manipulado por el cliente.
Esto significa que, al definir permisos centrales de RBAC para el personal, administradores y moderadores, esto debe hacerse (en términos generales) en Rails, no en JavaScript.
Por cierto, así es como Discourse implementa ahora el RBAC, utilizando lo que Discourse llama “guardian”, una clase de Ruby llamada class Guardian, aquí:
Si un desarrollador va a agregar verificaciones de RBAC en código JavaScript llamando a la API de Discourse, tenga en cuenta que este código puede ser comprometido porque el código que se ejecuta en el navegador puede ser manipulado.
Mi recomendación es asegurarse de que todo el código central de RBAC se ejecute en el lado del servidor y no intentar atajos en JavaScript del lado del cliente.
También existe el nivel de confianza 4 y los moderadores de categoría, en Discourse 2.5 y versiones posteriores.
Tengo un caso de uso similar: administro una pequeña comunidad sin fines de lucro en la que uno de nuestros usuarios se encarga de mantener los temas y el diseño.
No deseo otorgar acceso a datos privados de los usuarios (como direcciones de correo electrónico, etc.) a nadie más que a mí y a mi copropietario, aunque sí tengo cuatro moderadores.
Para que el diseñador pueda trabajar, he tenido que crear un sitio de prueba sin contenido donde él es administrador, y luego copiar manualmente los temas y componentes. Sin embargo, esto no es lo ideal, ya que algunos cambios requieren contenido para poder probarlos.
¿Por qué no agregar algo de contenido al sitio de preparación/pruebas? Esa sería la recomendación típica.
Así que deja que el desarrollador trabaje en el sitio de staging y suba los temas a GitHub. Sin embargo, aún tendrás que actualizarlos tú mismo. Podrías idear una forma de realizar la actualización mediante la API y permitir que el desarrollador la active.
Estoy trabajando en una herramienta que podría ayudar con eso.
Nosotros tenemos exactamente esta misma necesidad, ¿alguien ha resuelto esto por casualidad?
No sé si esto es útil en esta situación, pero si solo necesitas algo de contenido, existe la tarea populate de rake:
Gracias, desafortunadamente no es realmente útil en este momento.
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?
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?
¡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.
No, no lo es. Puede ir en contra de las normas de ese sitio, pero estas pueden y deben cambiar.
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.