Configurei uma categoria para rastreamento de bugs em nosso servidor Discourse. Gostaria de rastrear tanto as submissões de bugs públicas de usuários quanto os bugs enviados internamente no mesmo lugar.
Quero que os bugs públicos sejam visualizáveis por todos (portanto, tópicos privados não são uma solução). Dessa forma, podemos reduzir duplicatas e as pessoas podem comentar ou elaborar sobre um tópico existente.
Também quero que nossas equipes internas possam enviar bugs, mas não quero que eles sejam visualizáveis pelo público em geral, a menos que queiramos especificamente para um determinado tópico.
Podemos ativar o Sussurro (Whisper) nas respostas, mas não no tópico em si. Então, existe alguma maneira de definir a visualização por tópico?
Definir o tópico como ‘Não listado’ (Unlisted) quase faz o que queremos, exceto que temos um grupo de desenvolvedores que precisam vê-los, mas não estão definidos como moderadores ou administradores, eles estão apenas em um grupo.
Você pode ter duas versões desta hierarquia de árvore? Uma para uso interno e outra para uso externo. Você pode usar tags (ou tags automáticas) para ajudar a equipe interna a ver quais bugs existem tanto internamente quanto publicamente.
Alternativamente, se você for um cliente empresarial, poderá ter categorias de terceiro nível habilitadas.
Eu sou auto-hospedado, então posso colocar outro nível lá se eu quiser, mas novamente, não é a solução mais simples para o usuário.
Pelo que entendi, meu pedido não é possível.
Que pena. Isso seria resolvido tendo uma configuração de site para “Permitir que estes grupos vejam Tópicos Não Listados. Administradores e Moderadores sempre podem ver estes tópicos.”
Quão importante é para você que outros usuários não leiam esses tópicos?
Duvido que tópicos não listados sejam realmente uma solução para você. Quando você segue uma categoria, você também recebe uma notificação para cada tópico não listado que é criado. Essa notificação contém o link para que você possa visitar e ler o tópico.
Portanto, os tópicos não seriam visíveis apenas para o grupo específico.
Apenas as categorias controlam o acesso, mas se você quiser uma versão mais branda disso, você poderia fazer algo com CSS para fazer algo. . .
Ah. Talvez o que você deva fazer seja alterar suas permissões para que os desenvolvedores (que são estúpidos, preguiçosos ou descuidados demais para colocar as coisas na categoria certa) não tenham direitos de criação na categoria de bugs públicos. Então, se algo deve ser público, alguém que tenha atenção suficiente para ser confiável pode movê-los para a categoria pública.
Isso meio que anula o propósito da minha solicitação original. Eu quero uma categoria de bugs e controle sobre a visibilidade de tópicos individuais dentro dessa categoria.
Parece que deveria ser factível, mas com base no feedback, talvez não.
Eu acho que com qualquer processo que envolva ‘pode ser público, pode ser privado’ haverá margem para erro do usuário toda vez que alguém criar um tópico. Seja escolhendo a categoria certa, lembrando de clicar em ‘sussurrar’ ou adicionando uma tag que então faz alguma mágica CSS para escondê-la, e assim por diante. Há um ponto em que você tem que fazer essa escolha e uma oportunidade correspondente de estragá-la.
Eu acho que uma subcategoria é o caminho a seguir para ter confiança nas proteções de visibilidade. Se você não quiser ativar sub-subcategorias para isso (ou ajustar sua estrutura de categoria de nível superior com uma alternativa como Category Groups), você pode ter uma subcategoria extra em Suporte para #internal-bug-reports e, em seguida, usar o filtro de tópico para criar uma lista de tópicos personalizada incluindo tópicos de ambas as categorias, que você pode então adicionar à barra lateral para seus desenvolvedores usarem.
Apenas por diversão, testei se poderia mudar o post_type de um OP usando a API. E embora tenha funcionado, ele ainda apareceu na lista de tópicos para um usuário de teste não-sussurrante e, em seguida, gerou erros quando ele clicou nele. Portanto, parece que seria necessário algum trabalho de desenvolvimento adicional para suavizar isso (e também pode haver outros conflitos para o comportamento inesperado quando você começar a investigar).
Isso pode não ser tão ruim. Não tenho certeza se me importo se usuários regulares puderem ver os títulos.
Minha solução alternativa atual é semelhante:
Crie um tópico com um nome descritivo adequado.
O corpo consistirá em “Bug de rastreamento #”.
Salve
Edite a postagem e insira o # da URL para que o corpo agora leia “Bug de rastreamento #138”.
Sussurre todas as respostas adicionais.
Agora, basta adicionar meu grupo de desenvolvimento ao ‘Grupos permitidos para sussurrar’.
Não é tão elegante quanto eu gostaria, mas escrever o SOP para isso é bastante direto.
Isso tem o benefício adicional de permitir que um usuário regular adicione uma postagem ao tópico se ele tiver um bug que pareça semelhante ao título.
Portanto, parece que seria necessário algum trabalho de desenvolvimento adicional para suavizar isso (e também pode haver outros conflitos para o comportamento inesperado quando você começar a investigar).