Hola.\n\nAhora que podemos otorgar acceso específico a los susurros a grupos concretos, estamos muy cerca de poder eliminar el acceso de moderador para la mayoría de nuestros usuarios internos.\n\nNon-moderator access to whispers, cuando empezamos a eliminar el acceso, nos dimos cuenta de que nos faltaba una última pieza y tuvimos que revertir el cambio. Hacemos un uso intensivo de las asignaciones (a usuarios y grupos) en nuestra organización.\n\nTodo esto está “oculto” para nuestra comunidad de usuarios. Esto realmente nos funciona, porque a veces asignamos hilos a un grupo porque…\n\n- simplemente estamos transmitiendo comentarios (para su información)\n- necesitamos que se tome una medida\n- no sabemos si se necesita tomar alguna medida (y el grupo lo decidirá una vez que lo vea)\n\nSe confía en que los usuarios internos asignen hilos a otros grupos de la organización.\n\nLo que nos dimos cuenta, al empezar a revocar el acceso de moderador, es que la visibilidad de los grupos y la capacidad de asignar a grupos solo se pueden abrir hasta “solo miembros del grupo, moderadores y administradores” antes de que tuviéramos que permitir que los usuarios no internos pudieran ver y asignar a grupos.\n\nSería genial si estos permisos también se pudieran definir a nivel de grupo. Para nosotros, esta es la última pieza que falta.\n\n**¿Qué nos impulsa?**:\n\nCreo que es importante mencionar por qué estamos en este camino.\n\nTenemos ~170 moderadores en nuestra instancia. Estos usuarios no necesitan acceso a las direcciones de correo electrónico y a las direcciones IP de nuestros usuarios. Especialmente a medida que nuestra organización sigue creciendo, parece arriesgado tener esta información disponible para todos.
Solo como una aclaración aparte de la solicitud de función principal, ¿la configuración de administrador los moderadores ven correos electrónicos ayuda en algo con este problema?
Para ser sincero, no tenía idea de que existiera esa opción, ¡y de hecho está desactivada en nuestra instancia! Me hice pasar por otro moderador en nuestra instancia y, efectivamente, no pueden ver las direcciones de correo electrónico.
Juro que tenía acceso para ver correos electrónicos cuando era “solo” un moderador (no un administrador), tal vez teníamos una configuración diferente en ese entonces (nuestra instancia ha pasado por un viaje bastante largo en los últimos 8 meses).
Muchas gracias por señalarlo.
Así que eso definitivamente elimina algo de urgencia, y en general, todavía me gustaría ver que la plataforma siga avanzando hacia permisos flexibles basados en grupos en lugar de estas opciones más rígidas.
Lo siento, ¿puedes ampliar un poco aquí?
También estamos trabajando en un problema similar en Discourse, de hecho, no tengo acceso de administrador/moderador en nuestra instancia de desarrollo. Entiendo perfectamente las enormes ventajas de mantener bajo el número de administradores/moderadores.
¿Puedes explicar el problema?
Teniendo en cuenta que hay varios bloques de construcción en los que puedes apoyarte:
-
Moderación de categorías, puedes definir la moderación sobre categorías específicas para grupos específicos. Esto permite a los usuarios de alta confianza una mayor flexibilidad.
-
Sistema de niveles de confianza… en TL4 (manual) se desbloquea mucho.
-
Configuración del sitio
assign allowed on groups(que desbloquea la asignación para grupos específicos).
Claro. Me complace ampliar.
Tenemos un montón de equipos diferentes en nuestra empresa que contribuyen a nuestra Comunidad como expertos en la materia de la parte de nuestro producto de la que son responsables. Se crea un grupo para cada equipo y, cuando se requiere la experiencia de un equipo en un tema, el tema se asigna al equipo (y normalmente luego se asigna a un individuo, que se lo desasigna cuando ha contribuido todo lo que puede).
No queremos revelar a nuestros usuarios cómo funciona todo esto. Intentamos mantener las expectativas bajas (es soporte gratuito que ofrecemos a nuestros usuarios de código abierto), no queremos que los usuarios empiecen a preguntar “¿Por qué no pueden simplemente asignar esto al equipo de _____ ya?” – de hecho, no queremos que nuestros usuarios sepan que estos grupos existen.
Normalmente, estoy a favor de la transparencia radical… pero esto funciona muy bien para nosotros.
Y queremos que nuestros usuarios internos puedan ver todos estos grupos, los temas asignados a ellos y tener la capacidad de reasignarlos a otros grupos.
Pero los permisos de interacción a nivel de grupo:
- ¿Quién puede ver este grupo?
- ¿Quién puede ver los miembros de este grupo?
- ¿Quién puede @mencionar a este grupo?
- ¿Quién puede enviar mensajes a este grupo?
- ¿Quién puede asignar a este grupo?
Están limitados a los siguientes permisos
Esto significa que si queremos asegurarnos de que todos nuestros usuarios internos puedan ver/interactuar con los grupos de la manera que necesitamos, tenemos que otorgar al menos acceso de moderador. Esto no es ideal.
Espero que esto ayude a aclarar el problema. Avísame si puedo aclarar algo más.
Entiendo, ciertamente es un aprieto. Estoy 100% de acuerdo en que deberíamos pasar de:
A:
¿Qué grupos tienen permiso para X:
[mi-grupo/propietarios grupo1 grupo2 etc... ]
De hecho, esto probablemente simplificaría la interfaz de usuario y la implementación interna, que ya no tendría que razonar sobre enumeraciones y demás.
Lo más difícil de un puerto es que “propietarios del grupo” no es un grupo real, por lo que necesitaríamos algún tipo de nuevo primitivo para describir lo que significa. El ID del grupo no es suficiente.
¡Sería útil si fuera un grupo real!
Mi solicitud de función para exactamente eso:
Honestamente, me cuesta pensar en un caso de uso real en el que los propietarios de grupos no deban poder hacer todo en virtud de ser propietarios de grupos.
En cuyo caso, tal vez podrías ignorar ese problema y otorgar a los propietarios de grupos derechos de administrador. El resto de los permisos se delegarían luego a grupos individuales.
Te escucho, pero me preocupa mucho hacer cambios drásticos. Al admitir un simple grupo fantasma de “propietario del grupo”, podemos migrar completamente a una nueva interfaz de usuario sin romper nada para los usuarios existentes de la función.
¡Claro, entiendo totalmente tu perspectiva sobre esto!