¡Hola!
Quiero cambiar los permisos de los grupos de usuarios, por ejemplo:
Grupo de administradores: todos los permisos
Co-administrador: puede hacer todo, pero no puede abrir algunas secciones del panel de administración.
¿Cómo se hace? ¡Gracias!
Eso no es posible de forma predeterminada, ya que los administradores tienen acceso ilimitado a todas las secciones del foro. Dependiendo de qué tipo de permisos quieras revocar, ¿quizás degradarlos a moderador pueda ser útil?
El moderador no puede crear categorías y yo quiero eso
Los moderadores pueden crear categorías si habilitas la configuración moderators_create_categories en el panel de administración de Discourse.
¿Dónde lo encuentro? Revisé todas las categorías en el panel de administración y no vi nada que pudiera asignar a los moderadores.
*¿Existe algo como moderators_create_themes?
Ve a Administración > Configuración
Luego busca la palabra clave moderators_create_categories
¿Tu Discourse está actualizado?
Lo que preguntas es: “¿Existe algo como ‘los moderadores pueden colapsar todo el sitio creando un tema roto’?”. Estoy bastante seguro de que la respuesta será “No”.
Podrías instalar un tema remoto alojado en GitHub que un moderador pudiera modificar, pero un administrador aún tendría que integrar los cambios.
¿No sabes quién va a experimentar con los temas? ¿Cómo puedes hacer esa afirmación?
Hice esta pregunta porque no hay grupos con reglas personalizadas como se mencionó anteriormente.
Mi punto es que si confías lo suficiente en alguien como para permitirle cambiar temas, entonces puedes convertirlo en administrador.
Si deseas permitir que los no administradores modifiquen temas o cambien de otra manera lo que puede hacer un moderador, necesitarás un plugin personalizado.
No en mi escenario actual. Tenemos equipos de UX y diseño, y ellos solo son responsables de esa área, por lo que solo sería necesario el acceso a los temas.
Nosotros también tenemos este mismo caso de uso. Contamos con contratistas externos (diseñadores web) a los que queremos otorgar acceso a esto. Un administrador completo tendría acceso a todo, incluidas las discusiones de gestión privadas, lo cual no es deseable.
Sería ideal contar con un flujo de trabajo que permita a los diseñadores web enviar o probar cambios sin necesidad de tener acceso de administrador completo.
Hola @Joaquin_Menchacha
Gracias por tu publicación y por recordarnos este tema.
También deseamos (y tenemos previsto) refinar algunos de los controles de administración en el futuro.
Por ejemplo, nos interesa desarrollar un plugin (algún día) que se configure con variables en el archivo yml del contenedor y que restrinja ciertas acciones de administración (como descargar una copia de seguridad completa del sitio) solo a ciertos usuarios (IDs de usuario).
Esta idea de plugin está en mi lista de pendientes y, cuando tenga la oportunidad, la estudiaré con más detalle. Hasta ahora, ni siquiera he dado el primer paso de revisar el código y analizar la viabilidad de esta idea.
¿Alguien ha encontrado una solución aquí?
Tengo el mismo caso de uso, donde quiero otorgar acceso a temas y acceso a anuncios internos a algunos de mis miembros del personal.
La solución sencilla es confiar en las personas y hacerlas administradoras o moderadoras. Si no confías en ellas con el control total, pero deseas que tengan acceso adicional, necesitarás un complemento.
No es que no confíe en ellos. Pero cuando se trata de nuestro modelo de amenazas, crea una superficie de ataque adicional. ¿Qué pasa si el usuario específico se ve comprometido debido a la falta de seguridad de su parte? Hay muchas variables en juego.
Entonces exploraremos la opción del complemento.
Estoy de acuerdo: Discourse necesita controles adicionales para la personalización. Como han mencionado otros, se podría contratar a contratistas externos para que utilicen funciones de mayor nivel, protegiendo al mismo tiempo la información de los miembros.
La moderación por grupos es bastante buena, pero a veces podrías querer algunas funciones avanzadas de un moderador completo, pero no todas.
Un plugin podría ser útil. Sin embargo, al igual que el plugin Fusion de Usuarios se integró en el núcleo, deberían integrarse funciones de moderación/administración más robustas y personalizables para permitir más tipos de personal.
Estoy de acuerdo con otros aquí en que el modelo de control de acceso mejoraría con una capa adicional de granularidad RBAC (control de acceso basado en roles) que especifique qué pueden acceder staff y admin (para ciertas funciones, no para todas).
Por ejemplo, un sitio podría querer agregar más administradores; pero prefieren otorgar un conjunto más pequeño de privilegios RBAC de administrador; por ejemplo, otorgar o no otorgar la capacidad de descargar la copia de seguridad completa del sitio o acceder a ciertos archivos de registro de acciones del personal. Además, un sitio podría querer asegurarse de que algunos miembros del personal no tengan los permisos RBAC para ver las acciones del personal de administradores o desarrolladores, o solo ciertas acciones que se consideran más “privadas”.
A todos los expertos en ciberseguridad se les enseña (y lo saben por experiencia directa) que la mayor amenaza para cualquier organización es el “insatisfecho interno” y no los hackers o atacantes externos. No hay duda sobre este riesgo básico de seguridad de TI, y es conocimiento bien establecido para profesionales de seguridad de TI capacitados o con experiencia práctica. Por lo tanto, descartar la amenaza interna con “solo confía en tu administrador” o “debes confiar en tu personal” no es una solución técnica para los profesionales de TI. Incluso el personal más confiable, leal durante muchos años, puede comenzar a experimentar problemas de vida que pueden hacer que se conviertan en un “miembro del personal insatisfecho”. Además, es el personal más privilegiado el que comete más errores; y todos sabemos que, en general, los errores bien intencionados del personal/administrador causan más tiempo de inactividad que cualquier hacker.
Hace un tiempo, consideré modificar la clase Guardian de Discourse para nuestro sitio, pero tras examinar más a fondo esa clase, no me resultó obvio que existiera una “solución rápida” que me permitiera escribir una cantidad mínima de código de parche de mono para mejorar el RBAC de Discourse. Siendo perezoso por naturaleza y prefiriendo crear soluciones simples siempre que sea posible, dejé la idea en espera y pasé a otros proyectos de “clientes bien pagados”.
Posteriormente, consideré bajar un nivel en el código y transferir algunas de las funciones de staff y admin a developer, pero este enfoque requería demasiados parches de mono, lo que pensé que no era una buena idea en ese momento. Después de todo, si podemos lograr algo con un parche de mono en lugar de diez, obviamente un parche es mejor.
Aún no he tenido el tiempo ni una “necesidad urgente” para profundizar en esta parte del núcleo de Discourse y determinar si existe una mejora de plugin RBAC “fácil” que pueda escribir mediante un plugin “relativamente simple”.
Honestamente, creo que el problema es que aún no soy un super rubyista y, en su mayoría, me considero más un “aspirante” a programador en Ruby, LOL. Estoy seguro de que, muy probablemente, existe una solución simple de plugin RBAC por ahí, pero personalmente aún no la he encontrado y quizás una persona de Ruby mucho más experimentada pueda mirar rápidamente el código y ver cómo abordar esto.
Mi idea sería tener algunas nuevas configuraciones de sitio booleanas que limiten o otorguen permisos RBAC específicos según el rol, y luego agregar esos booleanos a la parte adecuada del código mediante un parche de mono en un plugin. Sin embargo, como mencioné, preferiría parchear un solo archivo, no “muchos”, para que sea limpio y simple, fácil de mantener.
Cuando tenga tiempo, investigaré más a fondo esta mejora de RBAC, ya que es interesante, sin duda.
Hola @jrgong
Esto no es difícil de implementar mediante un plugin, como probablemente ya sabes.
Básicamente, podrías crear una lista de miembros del equipo (por correo electrónico, nombre de usuario, etc.) como una configuración global, similar a como Discourse define a los desarrolladores por dirección de correo electrónico.
Luego, podrías usar esa GlobalSetting en algunos parches para permitir los dos casos de uso que te interesan.
El primer caso de uso: personalizar temas como miembro del equipo, es relativamente sencillo de implementar mediante un parche de monito en el núcleo, creo.
En cuanto al segundo caso de uso, con poco trabajo podrías bifurcar este plugin y rediseñar la restricción de acceso a rutas en este plugin (y cualquier otro cambio necesario):
Dado que la restricción para el plugin de anuncios está integrada en el plugin, es una buena idea modificar ese código para permitir que tu personal “autorizado” acceda a las partes de ese plugin que desees, basándote en tu propio control de acceso basado en roles (RBAC).
En otras palabras, ambos requisitos que necesitas son factibles si estás dispuesto a escribir el código; o, por supuesto, puedes pedir ayuda a uno de los expertos desarrolladores de plugins de Discourse en Marketplace.
Gracias @neounix, ¡realmente aprecio tus comentarios! Haré que un desarrollador lo solucione.
edición: ¿No hay otra forma de hacerlo sin bifurcar el plugin?
¿Y qué hay del acceso al plugin de chat Babble? ¿Eso también requeriría una bifurcación?
Estamos hablando de software.
Siempre hay muchas formas de hacer las cosas.
Te he dado mis recomendaciones.
