A ação de excluir usuário está localizada em diferentes botões de nível superior, dependendo do tipo de flag. Seria ideal que o botão Excluir sempre tivesse uma subação para excluir o usuário.
Aliás, as URLs são adicionadas à lista de filtragem se você excluir de uma revisão marcada manualmente, mas não de revisões postadas pelo usuário muito rápido.
Acabei de ter algumas coisas estranhas acontecendo relacionadas à sinalização de uma postagem em uma mensagem privada. Duas pessoas estavam na mensagem (eu e um novo moderador que estou no processo de integrar). Estávamos testando a sinalização, e ela sinalizou uma de suas próprias postagens. Ambos recebemos a notificação de que nossa mensagem foi sinalizada como spam e que deveríamos editar e corrigi-la, e nenhum de nós pôde reverter diretamente a ação de sinalização na postagem. Além disso, ela não apareceu na fila de revisão.
Enquanto a postagem estava oculta, selecionei a chave de engrenagem de administração da postagem, mas não consegui usá-la porque, de alguma forma, ela estava atrás do conteúdo da postagem. Veja a captura de tela.
Só quando editei a postagem é que ela foi desocultada.
Então… vários problemas:
Tenho adorado as melhorias aqui — finalmente tive a oportunidade de organizar meus pensamentos e reunir um pouco de feedback sobre isso:
Outra funcionalidade que deveríamos adicionar: fazer com que itens re-sinalizados não reapareçam na fila de revisão, a menos que o conteúdo da postagem tenha sido editado ou alterado de alguma forma. Isso deve ignorar automaticamente os novos itens sinalizados e não permitir notificar ou ocultar a postagem.
A ideia aqui é que algum moderador em algum lugar já tenha visto a sinalização e tratado o caso — e qualquer novo item (do mesmo tipo) seria tratado da mesma maneira.
Uma ressalva quanto ao acima: devemos provavelmente ignorar quaisquer novas sinalizações em vez de resolver automaticamente o item passível de revisão da mesma forma que a sinalização foi realmente tratada (por exemplo, concordar), pois isso poderia ter o efeito colateral indesejado de permitir que usuários que fazem sinalizações maliciosas aumentem suas pontuações de sinalização ao marcar coisas que os moderadores já resolveram com “concordar + manter”.
Ótimo ponto. Para complementar, aprovo regularmente posts que depois são marcados como spam pelo Akismet. Isso também não deveria acontecer.
É isso mesmo - os plugins provavelmente ainda devem ter a capacidade de sobrescrever a sugestão acima, se necessário, mas concordo que o Akismet não deveria fazer isso neste caso. Isso pode ser mais um problema do plugin Akismet, mas é um ótimo ponto.
Esse é um problema do plugin, vou aplicar uma correção.
Já comecei a investigar isso. Concordo que precisamos ignorar novas marcações em vez de resolvê-las automaticamente. Estava pensando em mostrar uma mensagem de erro quando alguém tentar re-marcar um post já revisado.
Também estava pensando que os usuários deveriam esperar cerca de 24 horas antes de poder re-marcar um post pelo mesmo motivo.
Como todos os itens pendentes mais recentes estão no menu Ver Tudo, a aba Revisão deve nos redirecionar para esse menu, em vez do menu Agrupado por Tópico.
Você tem tópicos padrão revisáveis configurado? Isso faz com que o padrão seja tópicos em vez de todos os itens, o que deveria ser o padrão.
Acabamos de mesclar este recurso:
De acordo com Discourse 2.4.0.beta11 Release Notes :
Usuários suspeitos enviados para a fila de revisão
Usuários suspeitos — aqueles que visualizaram menos de uma postagem e um tópico, mas personalizaram sua biografia — agora são enviados para a fila de revisão. Tais usuários têm alta probabilidade de serem spammers, já que a maioria dos usuários navega pelo site antes de dedicar tempo para preencher sua biografia.
Isso não está acontecendo conosco; novos usuários suspeitos aparecem em /admin/users/list/suspect como de costume, mas não na fila de revisão. Isso depende de alguma configuração?
Sim, o recurso depende da configuração “aprovar usuários suspeitos” (desativada por padrão).
Ótimo, está funcionando agora (talvez esse tipo de informação devesse ser adicionado às notas de lançamento).
Tenho um pequeno pedido que ajudaria a acelerar nosso processo de revisão: você poderia vincular o campo do site? Atualmente, precisamos copiar e colar, o que nos atrasa bastante.
Parece que você adicionou um campo de usuário. Infelizmente, não temos como saber se são URLs ou não.
O campo ‘Website’? Esse não é um campo personalizado (igual ao que temos aqui no Meta). Os outros dois são, mas não preciso que eles estejam com links diretos.
Faz sentido que o campo padrão do site web seja clicável. Seria legal se ele tivesse rastreamento de contagem de cliques.
Acho que você deve ser capaz de tornar seus campos personalizados clicáveis com um componente de tema.
Clique duplo, control - c, control - t, control - v, enter
Minha culpa! Verifiquei aqui no Meta e o usuário que eu olhei não tinha um site. Além disso, fiquei confuso com os outros campos de usuário logo abaixo. Isso vinculará o site para facilitar a revisão:
Depois de refletir mais sobre isso, uma janela de resfriamento de 24 horas parece adequada para sites menores, mas estou preocupado de que os usuários ainda possam sobrecarregar os moderadores em um site maior.
O que você acha de ter a variável de janela não sinalizável (ou pelo menos acessível em um plugin)? Qualquer coisa que possamos fazer para reduzir um possível ônus para os moderadores eu consideraria uma vitória.
Outro problema não relacionado: usuários altamente confiáveis podem ser vistos como tendo poderes de “moderação” com a capacidade de ocultar uma postagem com uma única sinalização. O antigo número mínimo para ocultar uma postagem pode ainda ser desejável como uma opção, para que nenhum membro da comunidade possa atuar como censor.
Sim, depois de muita ida e volta, não sou realmente contra reinstalar o número mínimo. Gostaria de ter certeza de que o cliente do @featheredtoast tentou as outras otimizações primeiro e tem certeza de que isso seria útil.
@Roman, poderíamos tornar essa janela de 24h configurável?
Feito aqui:
Pode ser ativado ou desativado com a configuração high_trust_flaggers_auto_hide_posts.
Pode ser configurado usando a configuração cooldown_hours_until_reflag (padrão de 24 horas).
