Hello!
I want to change user groups permissions, for example:
Admin Group - all permissions
Co Admin - can do anything but cannot open some sections on admin pane
How to do that? Thanks!
That’s not possible by default since admins have unrestricted access to all the sections of the forum. Depending on what kind of permissions you want to revoke, maybe demoting them to moderator can be helpful?
Moderator cannot create a categories and i want that
Mods can create categories if you enable the moderators_create_categories settings in your discourse admin.
4 Me gusta
Where i find that? I looked through all the categories in the admin panel and did not see anything that I could assign to moderators.
*Is there something like moderators_create_themes?
Go to admin > Settings
Then search for the keyword moderators_create_categories
4 Me gusta
Is your Discourse up to date?
What you are asking is, "Is there something like ‘moderators can crash the whole site by making a broken theme?’ ". I’m pretty sure that the answer is going to be “No.”
You could install a remote theme hosted in github that a moderator could change, but an admin would still need to pull in the changes.
You do not know who will tinker with the themes, how can you make that statement?
I asked this question because there are no groups with custom rules like it said above.
My point is that if you trust someone enough to change themes then you can make them an admin.
If you would like to allow non-admins to modify themes or otherwise change what a moderator can do you’ll need a custom plugin.
2 Me gusta
Not in my current scenario. We have UX and Design teams and they are only responsible for that area, so only access to the themes would be necessary.
2 Me gusta
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.
4 Me gusta
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.
3 Me gusta
¿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.
1 me gusta
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.
2 Me gusta
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.
1 me gusta
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.
1 me gusta
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.
2 Me gusta
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.
2 Me gusta