Gostaria de ter cerca de 20.000 grupos na minha instância do Discourse, isso é possível e afetaria o desempenho do site de alguma forma?
2 curtidas
Quantos usuários você terá?
Qual problema 20.000 grupos está resolvendo?
2 curtidas
Aqui está o cenário. Estou usando o Discourse para criar uma plataforma de discussão de artigos de pesquisa. Cada artigo é representado por uma tag com o ID do artigo. Todos os tópicos criados sob essa tag aparecem na página da tag para esse artigo.
O problema é que me falta a seguinte funcionalidade:
Tenho um processo de aprovação manual para autores de artigos enviados ao sistema. Quero dar-lhes a capacidade de editar posts que são marcados com a sua tag. Mas aprendi que não é possível dar permissões com base em tags.
Então, tive a ideia de ter um grupo por artigo e os autores de um artigo pertencerão ao mesmo grupo. Mas nem tenho a certeza se isso resolve o meu problema porque não tenho a certeza de como posso dar a capacidade de editar certos posts.
Agradeceria se pudesse ouvir se existe uma forma elegante de ter esta funcionalidade. Obrigado.
3 curtidas
Você quer que o autor possa editar as postagens de outras pessoas se for uma resposta ao artigo dele?
E você quer dizer postagens, não tópicos?
Sim, se uma postagem é uma resposta ou está relacionada ao artigo deles é atualmente determinado pela tag.
Mas eu também posso criar um grupo por artigo, se isso for ajudar.
E, idealmente, tanto as postagens quanto os tópicos devem ser editáveis.
Grupos são muito leves, você pode ter muitos milhares sem problemas.
Ter 20 mil categorias, por outro lado, será um problema de desempenho.
10 curtidas
As postagens não têm tags, os tópicos têm.
Não entendo por que você quer que as pessoas possam editar as postagens de outras pessoas. Você pode torná-las wikis, mas então qualquer um pode editá-las.
Ou talvez você queira que o tópico do usuário seja uma wiki para que qualquer pessoa possa editá-lo.
Eu simplesmente não entendo qual é o modelo em que faz sentido mudar as palavras de outra pessoa.
2 curtidas
Também comecei a questionar os méritos que a edição traz após considerar vários cenários. No entanto, seria bom ter um mecanismo para ver se uma pessoa respondendo é o autor do artigo ao qual o tópico está relacionado e acho que ainda não é possível com grupos.
Mais explicitamente: digamos que um usuário criou uma postagem marcando o artigo com o ID 5. Se o autor do artigo 5 postar uma resposta a esse tópico: A funcionalidade ideal seria indicar de alguma forma (pode ser um flair, título, um pequeno texto padrão no topo da postagem) que o usuário que está respondendo é o autor do artigo que está sendo discutido.
Se cada artigo for um tópico, e você atribuir o tópico OP ao autor, é trivial criar uma regra CSS para adicionar alguma diferenciação visual às respostas do OP em suas respostas posteriores.
1 curtida
Por que não ter apenas um tópico por artigo? Assim não há confusão. Você não precisaria de tags ou grupos.
Além disso, parece que você está confundindo o sentido de tópico do Discourse (uma coleção de postagens) e uma postagem (uma única mensagem de uma única pessoa que reside em um tópico).
Mas agora @falco se adiantou a mim…
1 curtida
@pfaffman @falco Tecnicamente, cada artigo é uma tag. O motivo é que um tópico não é suficiente para ter todas as discussões ou perguntas sobre um artigo. Existem muitos aspectos diferentes a serem discutidos e a principal motivação deste fórum é ter uma única fonte de todas as discussões que aconteceram em torno de um artigo. Portanto, cada artigo é uma tag e todos os tópicos criados sob a tag de um artigo podem ser vistos na página /tag/:paper_id.
É possível fazer o truque de CSS neste cenário? Posso criar um banco de dados externo definindo a relação entre as tags e seus respectivos “usuários autores”, se necessário.
1 curtida
Sim, você poderia ter um arquivo CSS que seria gerado automaticamente a partir da análise desse banco de dados.
Você também poderia fazer tudo isso no Discourse usando um plugin personalizado. Ele traria um campo extra no serializador de tópicos para posts onde o autor do post corresponde, que pode então ser aproveitado pelo aplicativo front-end.
1 curtida
Entendi, sou bem novo em plugins, mas vou tentar ver o que pode ser feito. Muito obrigado pelo conselho!
2 curtidas
Sinta-se à vontade para abrir tópicos em Dev sempre que ficar preso.
1 curtida
Então você entende que tópicos têm tags, não postagens. Acho que você está usando a palavra “postagem” quando quer dizer “tópico”.
Não acho que você respondeu a isso. Se você não quer que as pessoas editem as postagens de outras pessoas, acho que você não tem nenhum problema. Não consigo imaginar por que você gostaria que as pessoas editassem as postagens de outras pessoas, mas se você quiser, torná-las uma wiki pode ser a solução.
Marcar tópicos que são sobre um artigo específico com uma tag do artigo (como um DOI, mas acho que pode não haver um DOI neste ponto da vida do artigo) é uma ótima ideia e você pode fazer isso agora mesmo com a API. Além disso, usuários que podem editar o tópico (trust_level 3 e o proprietário do tópico) podem adicionar a tag; outros podem sinalizá-la e pedir para ser marcada (mas quem iniciou o tópico não sabe que é sobre o artigo?).
Não está claro para que você precisa de um plugin neste momento.
Você poderia dizer algo sobre onde os problemas de desempenho apareceriam? Ou seja, é em páginas específicas ou um problema geral? Se cada categoria estiver vinculada a um ou dois grupos, e o usuário médio tiver acesso a apenas 10-20 categorias no total, ainda é um problema ter 20 mil categorias?
Para o meu caso de uso (hipotético), é permitir que tópicos públicos sejam discutidos por meio de mensagens privadas de grupo. Essa abordagem poderia ser usada de algumas maneiras diferentes na tentativa de gerar discussões públicas produtivas em torno de tópicos polarizadores. Essencialmente, as discussões poderiam ser gamificadas pedindo às pessoas que se juntassem a equipes (grupos) relacionadas a um tópico específico e, em seguida, seguissem um conjunto de regras para responder ao tópico público como uma equipe.
Estou preparado para lidar com os problemas de UI que milhares de grupos poderiam criar para a equipe do site. Percebo que este é um caso de uso inesperado para os grupos do Discourse, então estou postando sobre isso aqui, caso haja algum problema de desempenho óbvio que eu esteja perdendo.
1 curtida
Bem, isso faz mais sentido do que eu imaginava. 
Acho que existe algum recurso de grupo criado pelo usuário em desenvolvimento, mas suspeito que ainda esteja longe.
1 curtida
Isso seria ótimo, mas por enquanto pode ser feito com a API.
1 curtida
Oooh. Estou começando a sair do tópico aqui, mas você poderia usar uma dessas coisas de API que recebem um webhook para cada novo tópico e, em seguida, criam um grupo para ele. Nenhum plugin é necessário. Não sei por que não pensei em ter o Discourse em ambos os lados de um desses serviços antes.
E o GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows apareceu na minha mesa hoje. Parece que você poderia fazer com que ele fizesse o trabalho em vez de pagar por um desses serviços. Duvido que ele tenha suporte ao Discourse pronto para uso, mas deve ser fácil o suficiente para fazê-lo funcionar.
1 curtida