Na nossa empresa, usamos “whispers” extensivamente para nos comunicarmos internamente sobre tópicos.
Quase todas as funções em nossa organização (Vendas, Serviços, Desenvolvedores, Gerentes de Produto, Gerenciamento de Comunidade, UX, Documentação) desempenham um papel em nossa comunidade de usuários. Para nós, isso significa que cada funcionário deve poder ver os “whispers”.
No Discourse, você precisa ser membro do grupo staff para ver os “whispers”. Para nós, isso significa conceder acesso de moderador a mais de 300 pessoas. Estes são usuários que, de outra forma, ficariam bem com TL4.
Resumindo: Todos os nossos funcionários precisam ver os “whispers”, poucos precisam ser moderadores.
Acharíamos muito útil se:
Houvesse uma configuração que permitisse aos usuários TL4 ver “whispers”, ou…
Se fosse possível listar os grupos que deveriam poder ver “whispers”, em vez de permitir apenas o grupo staff.
Certamente um problema muito interessante e concordo plenamente que essa permissão deve ser baseada em grupo.
Infelizmente, esta é uma grande mudança devido à forma como projetamos muitos dos internos.
À primeira vista, pode parecer uma mudança simples… basta reescrever esses dois métodos:
Mas os internos da mudança no Discourse correm bem fundo.
Temos até esta coluna que rastreia o highest_post_number_including_whispers… mas é chamada de highest_staff_post_number.
A outra complexidade aqui é que precisaríamos de uma verificação de grupo para determinar se um usuário pode ver um sussurro e agora a verificação é mais barata, pois simplesmente vamos ao registro do usuário.
Estou marcando isso para discussão interna e verei se há algo que possamos fazer aqui, mas infelizmente a complexidade é bastante alta.
Talvez uma abordagem diferente seria criar um novo nível de associação de funcionários?
Admin > Moderador > Equipe
Eles ainda poderiam se qualificar como ‘funcionários’, mas não apareceriam na página ‘sobre’.
Tive outras ocasiões em que seria útil ter a capacidade de marcar outros funcionários em conversas, mesmo que eles não estejam acompanhando a maior parte da atividade na comunidade (por exemplo, encaminhar para a equipe de produto para feedback relevante), mas não queria torná-los moderadores pelos outros privilégios.
Eu entendo, mas nosso padrão geral tem sido mudar para permissões baseadas em grupos hiperflexíveis. Já fizemos isso para assign e solved, e expandiremos para cada vez mais partes.
Uma solução alternativa que pensei é usar o recurso de chat sobre um tópico e dar acesso apenas à equipe e ao seu grupo de equipe a esse canal, usando-o para sussurros em vez do recurso de sussurro real.
@Colin_Mueller a alteração já deve estar ativa no seu site
Obrigado pela sugestão, é realmente algo que muitas pessoas desejaram. Há um pouco de um padrão repetido aqui, usar TL como um portão ou Staff como um portão tende a ser muito menos flexível do que permitir permissões baseadas em grupo.
