If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?
End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue
This is an interesting use case and I’d like to help you get it working.
Actions for reviewable types are returned from the build_actions method.
What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.
That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.
Robin,
Estou atualmente preparando um PR para o Discord OAuth Plugin, principalmente para armazenar mais informações do usuário do Discord no Discourse. Estou tentando usar seu modelo ReviewableUser para manter a funcionalidade que implementa aprovação automatizada.
Como a implementação atualmente cria uma revisão para novos usuários de forma assíncrona, preciso verificar se tal revisão foi criada e limpá-la.
Infelizmente, estou recebendo um erro Ruby muito estranho e me perguntei se você já o encontrou.
O código é:
def after_create_account(user, auth)
super
data = auth[:extra_data]
if !user.approved && data[:auto_approve]
user.approved = true
user.approved_by_id = Discourse.system_user.id
if reviewable_user = ReviewableUser.find_by(target: user)
reviewable_user.set_approved_fields!(user, Discourse.system_user)
end
end
end
Assim que o ReviewableUser.find_by é executado, recebo uma exceção:
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
Embora eu achasse que estava fazendo bons progressos no meu Ruby, não entendo por que isso está acontecendo.
Será um problema de caminho? Já tentei vários requires, mas isso só complica mais as coisas.
É muito parecido com padrões semelhantes em outras partes do código principal. Qualquer ideia é muito apreciada!
Repositório aqui, se precisar: discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
Esse erro constante não é muito informativo, não é? Acredito que tenha a ver com engines e namespaces do Rails. Uma coisa rápida que você pode tentar é ::ReviewableUser, com dois dois-pontos antes. Isso indica que deve usar o namespace raiz, não o da engine.
Esse código também parece um pouco desatualizado para a API reviewable. Deveria ser algo assim:
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
Isso resolveu o erro. Eu assumi que, como não conseguia encontrar a Classe antes, ela estava sendo tratada como uma Constante? De qualquer forma, isso foi resolvido, brilhante, muito obrigado! Estou desimpedido!
Então, o motivo pelo qual eu tinha isso:
user.approved = true
user.approved_by_id = Discourse.system_user.id
antes de:
reviewable.perform(:approve, Discourse.system_user)
é porque a adição à fila de revisão é assíncrona. No job, a revisão só é criada se o approve for falso em (discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub):
if user = User.find_by(id: args[:user_id])
return if user.approved?
@reviewable = ReviewableUser.needs_review!(
target: user,
created_by: Discourse.system_user,
reviewable_by_moderator: true,
payload: {
username: user.username,
name: user.name,
email: user.email
}
)
Existe o risco de o job ser disparado depois de você ter testado a entrada de revisão?
O resultado disso é que a entrada de revisão parece não existir, mas o job está apenas aguardando para ser executado. O job então é executado e cria a entrada de revisão, e você perdeu a oportunidade de limpá-la, pois seu código de teste já foi executado.
É uma condição de corrida potencial?
Defina approved como true antes de verificar a entrada de revisão e você terá resolvido o problema (porque uma revisão nunca será criada após isso, já que é uma dependência).
Eu me deparei com esse problema ao testar meu código — no dev funcionou, mas na produção falhou, pois as coisas foram executadas em uma ordem diferente.
NB: Agradeço que você não tenha escrito isso para suportar este caso de uso, mas acho importante permitir que plugins possam aprovar automaticamente novos usuários em circunstâncias especiais (como o plugin do Discord, que faz isso se o usuário for membro de uma guilda confiável).
De fato, o registro auditável é criado de forma assíncrona, o que é problemático nessa situação, pois o login criará o usuário e o registro de aprovação pode não estar disponível.
Uma solução melhor seria não criar o registro auditável nessa situação; no entanto, isso exigiria alterações no núcleo para funcionar corretamente. Poderia funcionar da seguinte maneira:
skip_approval: true.Obrigado, Robin, sim.
Por enquanto, optei pela minha solução alternativa, ciente de que precisará ser resolvida antes que o acesso direto à API seja removido.
A equipe tem interesse em priorizar isso antes que o acesso de gravação direto ao user.approve seja removido?
Acredito que essa alteração quebrará o recurso atual de autoaprovação de Guild confiável no plugin Auth Discord Login (mesmo sem a PR que acabei de abrir para esse plugin). @featheredtoast
Ficarei feliz em atualizar minha PR com suporte a essa alteração, caso seja implementada.
Não vejo nós removendo isso tão cedo. Não quero depender disso para sempre, mas deve ser útil por um tempo.
A fila está ótima e o agrupamento por tópico também é útil.
No entanto, pelo que pude ver, não há uma maneira de selecionar e processar postagens em massa. Cada postagem precisa ser processada individualmente.
A seleção e o processamento em massa seriam uma grande economia de tempo!
Acho que seria um ótimo aprimoramento. Para ser justo, a fila de Flags nunca teve operações em lote, então não é como se isso fosse uma regressão.
Além disso, algumas operações, como “Suspender”, são um pouco estranhas quando você está trabalhando com várias linhas. Seria necessário restringi-las às operações básicas para fazer algum sentido.
Encontrei um pequeno problema: alguém postou em uma categoria que exige aprovação, então o post apareceu na fila de revisão. Eles postaram na categoria errada, então tentei alterá-la na fila de revisão. Não houve problema, exceto que a categoria para a qual estou tentando mover o post exige uma tag específica, mas essa tag é restrita à nova categoria. Como o post na fila de revisão ainda considera que está na categoria original (que não permite essa tag), fiquei travado. É fácil aprovar o post e alterá-lo depois, mas parece algo que deveria ser corrigido.
Sei que isso deveria ter sido corrigido, mas os URLs ainda não estão sendo adicionados à lista de monitorados. Provavelmente nem faz tanta diferença mesmo, já que a ação para URLs monitorados é
Só para confirmar: você atualizou para a versão correta? Eles devem ser filtrados se não forem compatíveis com onebox ou internos.
Sim, estou na v2.4.0.beta2 +66. Da próxima vez que isso acontecer, farei uma cópia da postagem.
Sim, após clicar em “Excluir Usuário” na fila de revisão, o e-mail e o endereço IP foram adicionados às listas filtradas, mas nenhuma URL. A publicação era:
Quer [Serviço de Redação Acadêmica](https://myassignmenthelp.com/uk/academic-writing-service.html) online no fornecedor de serviço de redação acadêmica nº 1 do mundo, Myassignmenthelp.com. Serviço profissional de redação acadêmica oferecendo ampla variedade para estudantes com o melhor preço.
Nas minhas lembranças, URLs nunca foram adicionadas automaticamente à lista de verificação? Bem, acho que foram. Verifiquei minha instância e há várias URLs lá 
Ah, sim, lembrei. Elas realmente não fazem nada, são apenas informativas.
Você pode adicionar esses nomes de domínio às palavras monitoradas para que não possam ser inseridos, mas você terá que fazer isso manualmente.
É por isso que seria bom se eles fossem adicionados à lista monitorada — mesmo que nenhuma ação automática seja tomada nas URLs, isso nos permitiria ver qual spam está sendo postado. Lembre-se de que os moderadores podem usar a fila de revisão, mas não podem (acho) adicionar palavras observadas.
Algum feedback menor sobre a UX: seria ótimo se a fila de revisões lembrasse das minhas configurações. Como trabalhamos com uma equipe de moderadores, estou pessoalmente mais interessado em ver novas denúncias e ordeno por ‘Criado em’, mas essa configuração não ‘permanece’.
Essa não é uma sugestão ruim. Felizmente, por enquanto, existe uma solução alternativa: os filtros de pesquisa são salvos na string de consulta (URL). Se você marcar um filtro como favorito, sempre poderá retornar a ele.
