En nuestra empresa, utilizamos “whispers” (mensajes privados) extensamente para comunicarnos internamente sobre temas.
Casi todos los roles en nuestra organización (Ventas, Servicios, Desarrolladores, Jefes de Producto, Gestión de Comunidad, UX, Documentación) juegan un papel en nuestra Comunidad de usuarios. Para nosotros, esto significa que cada empleado debería poder ver los “whispers”.
En Discourse, tienes que ser miembro del grupo staff para ver los “whispers”. Para nosotros, eso significa otorgar acceso de moderador a más de 300 personas. Estos son usuarios que de otra manera estarían bien con TL4.
En resumen: Todos nuestros empleados necesitan ver los “whispers”, muy pocos necesitan ser moderadores.
Realmente nos sería útil si:
Hubiera una configuración que permitiera a los usuarios TL4 ver los “whispers”, o…
Si fuera posible listar los grupos que deberían poder ver los “whispers”, en lugar de solo permitir el grupo staff.
Alguna mejor solución en la que no hayamos pensado
Ciertamente un problema muy interesante y te entiendo perfectamente en cuanto a que este permiso debería basarse en grupos.
Lamentablemente, este es un gran cambio debido a la forma en que diseñamos gran parte de la arquitectura interna.
A primera vista, puede parecer un cambio simple… solo reescribir estos dos métodos:
Pero los cambios internos en Discourse son bastante profundos.
Incluso tenemos esta columna que rastrea el highest_post_number_including_whispers… pero se llama highest_staff_post_number.
La otra complejidad aquí es que necesitaríamos una verificación de grupo para determinar si un usuario puede ver un susurro y ahora la verificación es más barata porque simplemente vamos al registro del usuario.
Estoy marcando esto para discusión interna y veré si hay algo que podamos hacer aquí, pero desafortunadamente la complejidad es bastante alta.
¿Quizás un enfoque diferente sería crear un nuevo nivel de membresía de personal?
Admin > Moderador > Equipo
Aún podrían calificarse como ‘personal’ pero no aparecer en la página ‘acerca de’.
He tenido otras ocasiones en las que sería útil poder etiquetar a otros empleados en conversaciones, incluso si no siguen la mayor parte de la actividad en la comunidad (por ejemplo, remitir al equipo de producto para recibir comentarios relevantes), pero no quería convertirlos en moderadores por los otros privilegios.
Te escucho, pero nuestro patrón general ha sido pasar a permisos grupales hiperflexibles. Ya lo hicimos para “asignar” y “resolver”, y lo ampliaremos a más y más partes.
Una solución alternativa que se me ocurrió es usar la función de chat sobre un tema y dar acceso solo al personal y a su grupo de equipo a ese canal, y usarlo para susurros en lugar de la función de susurro real.
@Colin_Mueller el cambio debería estar activo en tu sitio
Gracias por la sugerencia, es algo que mucha gente deseaba. Hay un poco de patrón repetitivo aquí, usar TL como puerta de entrada o Staff como puerta de entrada tiende a ser mucho menos flexible que permitir permisos basados en grupos.
