Fora de questão, mas me perguntaram várias vezes se há uma possibilidade no futuro de dar um alternador de interface do usuário para os grupos especificados em Grupos permitidos para tópicos privados para que eles possam ver a visualização filtrada por si mesmos.
Este problema foi resolvido no último commit.
Para manter as coisas (relativamente) simples e performáticas, os links de tópicos privados nunca gerarão um backlink agora.
Obrigado por relatar, Stephen!
2 posts foram mesclados em um tópico existente: Renomear “tópicos privados” para “tópicos de mensagens pessoais”
Perda de memória de curto prazo. Eu já tinha visto isso antes.
Fiquei pensando, porém, se essa forma de filtrar tópicos de todas as listas de tópicos causará algum problema de desempenho?
Ainda não ouvi nenhuma reclamação. O plugin foi escrito com o desempenho em mente.
Se uma postagem no tópico privado for marcada como resolvida, então essa postagem aparece na aba resolvida do perfil do proprietário da postagem e é visível para todos.
Obrigado por relatar isso. Vamos resolver isso o mais rápido possível.
O problema relatado por @SubStrider foi resolvido. Por favor, atualize para a versão 1.5.12 do plugin.
Obrigado novamente por relatar isso, @SubStrider ![]()
Encontrei algo que eu chamaria de bug. Talvez não seja um problema tradicional no código, talvez mais um bug de usabilidade no design. Ainda assim, causou alguns problemas que eu gostaria de evitar no futuro. Contexto a seguir:
Instância do Discourse com um número de três dígitos de usuários, usada como substituta de lista de e-mail. Cerca de 40 categorias (= listas de e-mail) com um grupo correspondente para gerenciamento de membros. Algumas das categorias usam o plugin de tópicos privados para simular uma lista de e-mail onde não membros (mas membros de outras listas) podem escrever. Até aí tudo bem.
O problema:
Hoje, o usuário administrador escreveu um tópico em algumas das listas para verificar com os membros da lista sobre algumas configurações. Tudo bem para categorias “normais”/fechadas onde apenas os membros do grupo correspondente recebiam a mensagem. Não funcionou bem para as categorias que usam o plugin de tópicos privados. Lá, todas as centenas de usuários, independentemente de serem membros daquela categoria/grupo específico ou não, receberam um e-mail com a mensagem. Lá, todas as centenas de usuários, todos membros da categoria, pois os direitos da categoria foram dados a ![]()
todos[1] mas independentemente de serem membros do grupo específico definido nas configurações do plugin da categoria para ter direitos visíveis ou não, receberam um e-mail com a mensagem.
Como reconhecido mais tarde, a configuração do plugin do site Grupos permitidos para tópicos privados ainda estava usando o grupo padrão Admin.
(Aliás, já tivemos esse problema antes, onde um usuário, sendo administrador e tendo sua conta “normal”, enviou (acidentalmente pelo endereço de e-mail associado ao usuário administrador e não ao usuário normal) um documento interno para uma categoria usando o plugin de tópicos privados, resultando em vazamento de informações. Na época, eu não conectei os pontos a este plugin, só hoje ficou claro para mim o que havia acontecido naquela época)
Comportamento esperado:
Eu consigo ver o raciocínio por trás da escolha do design, que postagens/e-mails de administradores são sempre visíveis/enviados por e-mail. Mas neste caso, a intenção era informar apenas os membros da categoria/grupo. Que algumas centenas de e-mails foram enviados para todos nesta instância do Discourse foi muito pouco transparente (e desagradável) para mim.
Correção possível:
Gostaria de melhorar essa situação. Como o envio de e-mails está disponível, uma simples caixa de diálogo de confirmação não funcionará. Talvez isso possa ser uma configuração global no plugin ou por categoria usando o plugin, para tratar postagens de administradores como visíveis para todos ou visíveis apenas para membros da categoria/grupo? Isso pelo menos aumentaria a conscientização ao configurar uma nova categoria.
o que não deveria ser usado, mas
trust_level_0deveria ser usado, veja OP ↩︎
Você pode me enviar uma mensagem privada com todas as informações que você puder pensar que sejam relevantes, incluindo:
-
as versões do Discourse e do plugin
-
as configurações do plugin
-
outros plugins que você instalou
-
as configurações de segurança da categoria e as configurações específicas do plugin para uma categoria afetada
-
as configurações de notificação
-
o modo de lista de e-mail está ativado?
-
se os usuários que inadvertidamente receberam a notificação por e-mail também conseguem ver o tópico ao visitar a categoria
-
qualquer outra coisa que possa importar para nos ajudar a reproduzir
Obrigado pela sua rápida resposta!
Feito. E as perguntas me ajudaram a encontrar a causa raiz (configurações do site: configurações do plugin: Grupos permitidos para tópicos privados). Então, em termos de código, funciona como projetado, na minha opinião, um problema de UX que se beneficiaria de algumas melhorias. ![]()
Uma das coisas contraintuitivas é que os tópicos privados não funcionam corretamente quando o acesso é concedido a ‘todos’. Isso é mencionado no OP, mas para ser honesto, eu mesmo já caí nisso mais de uma vez. Adicionei um aviso nas configurações que aparece quando tópicos privados são ativados em uma categoria acessível a ‘todos’.
Obrigado novamente ao @RGJ por dedicar tempo para depurar e pensar sobre o problema comigo, ajudando-me a identificar meu erro de configuração ao usar o grupo everyone. Como em minha instalação apenas usuários logados têm acesso aos conteúdos do Discourse, inicialmente falhei em entender a diferença entre everyone e trust_level_0 – mas agora aprendi que o Discourse lida com eles de maneira bem diferente. Portanto, nenhum problema com o plugin, e ainda mais grato pelo aviso adicionado, pois temo que eu teria caído nessa armadilha mais cedo ou mais tarde novamente… ![]()
Seria possível para os usuários terem um botão que crie um tópico individual como privado? Usamos isso em nosso curso universitário e gostaríamos que as postagens dos alunos fossem visíveis por padrão, mas que os alunos tivessem a capacidade de marcá-las como privadas ao postá-las.
Receio que as implicações de desempenho seriam muito grandes, e estaria fora do escopo deste plugin.
EDIT
Use este plugin Topic OP moderation Plugin
5 publicações foram mescladas em um tópico existente: Restringir a postagem em uma categoria até que eles “curtam” um tópico
Se você puder fornecer mais informações sobre o processo:
- Quando o aluno postar, você deseja que ele tenha a opção de decidir entre público/privado?
- Eles devem ter permissão para reajustar a publicidade do tópico após
xtempo?
Uma solução alternativa de baixo esforço seria trocar o tópico para uma mensagem direta (DM), e vice-versa. Endereçar a um grupo.
Isso requer o envolvimento do moderador para listar como público a partir de DM/privado a partir de tópico.
@RGJ, por favor, mova esta postagem de volta. Ela não deveria estar aqui.
Feito, meu erro, de fato não deveria ter se movido junto com aquelas outras postagens.
No entanto, não acho que qualquer discussão adicional sobre este caso de uso específico pertença aqui também. Por favor, mantenha a discussão focada no plugin Private Topics.
Estou recebendo um aviso de descontinuação no console para este plugin:
deprecation-identify-source.js:15 DEPRECATION: [PLUGIN discourse-private-topics] Importar `inject` de `@ember/service` está obsoleto. Por favor, importe `service` em vez disso. [id de descontinuação: importing-inject-from-ember-service] Isso será removido no ember-source 7.0.0. Veja https://deprecations.emberjs.com/id/importing-inject-from-ember-service para mais detalhes.
