Gostaria de usar um webhook para remover spammers do nosso banco de dados central quando os excluo na fila de revisão, mas nenhum evento é acionado ao configurar meu webhook dessa forma. Isso é esperado, ou estou interpretando mal a parte de ‘… e quando seu status for atualizado’?
1 curtida
O webhook “user delete” é acionado?
3 curtidas
Sim. Infelizmente, não está passando uma exclusão e eu gostaria de agir especificamente apenas quando um usuário foi excluído e bloqueado por IP.
1 curtida
Gostaria de solicitar a funcionalidade de ocultar automaticamente as imagens por padrão, especificamente para posts sinalizados por usuários TL0. Embora seja necessário visualizar imagens inadequadas e agir de acordo com os padrões de cada comunidade, seria útil ocultar essas imagens para quem está em ambientes de escritório ou trabalhando de casa com crianças por perto (como costumo estar).
6 curtidas
A API para ‘contornar’ a necessidade de pontuação na fila de revisão ainda não é suficiente ao longo do tempo, pois a pontuação é recalculada periodicamente. Se a fila não for tratada no momento da criação do item revisável, o item ‘forçado’ pode desaparecer das listas filtradas antes que os moderadores possam revisar esses itens.
Talvez devéssemos adicionar um campo booleano de ‘revisão-forçada’ ao modelo de item revisável, que seja incluído na consulta de pontuação aqui.
5 curtidas
As imagens de usuários TL0 já são borradas por padrão. Isso pode ser desativado por meio da configuração blur_tl0_flagged_posts_media.
Isso também já foi feito. Quando a flag force_review está definida como true, os reviewables pendentes aparecerão na fila, mesmo que não atendam à pontuação mínima de visibilidade.
8 curtidas
@Roman — Desculpe, ainda não consegui retornar sobre isso. Se ainda for potencialmente útil, tenho os logs e extraí alguns registros (com dados de identificação removidos). Estamos rodando atualmente na versão 2.6.0beta3. Todos os erros de “inteiro fora do intervalo” parecem ocorrer no mesmo tipo de registro.
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
1 curtida
Também seria interessante ter uma maneira de ver uma lista de itens para revisão que já foram revisados, filtrados pelo moderador que lidou com as bandeiras. O filtro “atribuído a” ao procurar em bandeiras resolvidas parece semanticamente muito semelhante a alguém procurando por um filtro “tratado por”, mas são diferentes.
O filtro “atribuído a” para bandeiras/itens de revisão resolvidos deve consultar quem tratou das bandeiras, ou isso pode ser um filtro separado?
4 curtidas
Acho que essa é uma ótima sugestão, @Roman. Você pode adicionar à sua lista?
5 curtidas
Estou usando um webhook e a API para adicionar novos tópicos na Fila de Revisão, para que os moderadores possam verificar a conformidade do novo tópico. Atualmente, estou marcando o primeiro post do novo tópico como flag usando a API. Isso funciona, mas parece algo negativo ao visualizar o histórico administrativo do usuário. Existe outra forma que não faça o usuário parecer mal?
1 curtida
Há algum motivo para você não poder usar aprovar novos tópicos, exceto para nível de confiança? Isso já está integrado ao Discourse.
2 curtidas
Concordo que isso funcionaria para muitos casos de uso. Nós exigimos tags de vários grupos de tags, o que não é suportado pelo Discourse. Queremos permitir o novo tópico, sem aprovação, mas garantir que as tags estejam corretas conforme o tempo permitir.
Acho que o que estou sugerindo é uma maneira de colocar itens arbitrários na fila de revisão. Atualmente, existem três tipos suportados: postagem sinalizada, postagem em fila e usuário. Estamos usando a postagem sinalizada porque é a mais próxima do que queremos, mas seria bom colocar um item “revisar tags” na fila de revisão, mesmo que só possamos fazer isso pela API.
1 curtida
Não há uma maneira fácil de fazer o que você deseja.
A melhor maneira de fazer isso seria criar um plugin que adicione um novo tipo de conteúdo avaliável e, em seguida, algum tipo de endpoint para criá-los.
1 curtida
Existe alguma maneira de desativar essa caixa de diálogo? Quase que exclusivamente rejeitamos spammers, e isso apenas adiciona um clique ao nosso fluxo de trabalho:
3 curtidas
Já postei sobre o mesmo problema aqui: Account rejection email - #11 by simon.
3 curtidas
2 curtidas
Existe uma maneira de adicionar um revisável do tipo “User” à fila de revisão via API? Ou isso só é acessível ao código que cria um novo usuário?
Meu caso de uso é que quero que os moderadores revisem quaisquer atualizações de usuários para garantir que estejam em conformidade com a política. Então, tenho um webhook de user_updated e quero colocar o usuário atualizado na fila de revisão.
Consegui fazer engenharia reversa de como sinalizar uma postagem (/post_actions…) porque posso sinalizar uma postagem manualmente e observar o tráfego de rede, mas não sei como fazer o mesmo para um User. Imagino que seja algo como /user_actions…
1 curtida
Não há como fazer isso via API no momento. Acredito que você precise adicionar um plugin que intercepte uma atualização de um usuário e crie uma revisão.
2 curtidas
2 posts were split to a new topic: Responding to post approvals
Olá, esta é uma crítica construtiva à fila de revisão.
Sei que algumas melhorias foram feitas nos botões “Rejeitar / Aprovar” para torná-los menos ambíguos (“Estou aprovando a postagem ou estou aprovando a sinalização?”). Mas ainda há um duplo significado para esses status, o que torna a revisão da lista de itens já tratados bastante confusa para mim, porque o filtro de Status e o Status no canto superior direito não significam realmente nada. Aqui estão alguns exemplos:
Postagem aprovada sinalizada por digitar muito rápido –\u003e Postagem aprovada –\u003e Status: Aprovado
Sinalização aprovada em postagem inadequada –\u003e Postagem rejeitada –\u003e Status: Aprovado
Usuário rejeitado por spam no perfil –\u003e Usuário suspenso –\u003e Status: Rejeitado
Sinalização rejeitada em uma postagem –\u003e Postagem permanece –\u003e Status: Rejeitado
Portanto, parece que é necessário diferenciar entre os seguintes status, e alguns itens podem ter ambos:
- Usuário/postagem aprovado(a)
- Usuário/postagem rejeitado(a)
--- - Moderação aprovada
- Moderação rejeitada
Outra sugestão de melhoria no caso de spammers de perfil de usuário, eu apreciaria uma opção para excluir a conta e bloquear o e-mail, mas não o endereço IP, pois eles frequentemente usam faixas de IP compartilhadas que usuários legítimos também podem estar usando.
1 curtida