Esta nota tem como objetivo resumir minha experiência de administração ao silenciar alguns usuários. Não estou necessariamente pedindo mudanças, apenas citando os desafios que podem se traduzir em solicitações na revisão.
Quando preciso silenciar um usuário devido a e-mails devolvidos, não quero que um e-mail seja enviado a ele para notificá-lo do evento.
Não vejo uma opção de administrador para adicionar um motivo de silenciamento personalizado à lista existente. Gostaria de adicionar “E-mails devolvidos”.
Gostaria de definir uma das opções de período de silenciamento disponíveis como padrão. Não quero ter que definir o período de tempo no menu suspenso para cada evento.
Quero aconselhar o usuário sobre o motivo pelo qual ele foi silenciado, com mais informações do que a “razão” de uma linha. A caixa está lá para enviar um e-mail ao usuário com uma nota, mas novamente, isso envia um e-mail ao usuário. Eu só quero enviar uma mensagem a ele porque sei que o e-mail não funciona.
Outros e-mails do Discourse são enviados a um usuário após ele ter sido bloqueado ou silenciado? Para este cenário específico e possivelmente outros, não quero que mais e-mails sejam enviados a este usuário, especialmente se ele se inscreveu em muitas notificações.
Sobre a exclusão de um usuário neste mesmo cenário: podemos simplesmente excluir o usuário e também podemos “excluir e banir o endereço de e-mail e o endereço IP”. Por que esses estão vinculados? Gosto da ideia de banir um endereço de e-mail. Raramente posso querer banir um endereço IP. Mas banir um IPv4 é complicado por uma série de razões - talvez esteja tudo bem com IPv6, mas ainda não chegamos lá. Até que esses conceitos sejam separados, não podemos simplesmente banir um endereço de e-mail? Se eu soubesse mais sobre os internos do Discourse, ficaria feliz em criar um script para limpar itens específicos das listas de banimento, mas não sei onde encontrar esses dados.
Temos o MaxMind ativo para este site e eu gostaria de usar o endereço IP para obter uma localização para ajudar a determinar se o usuário deve ser apenas silenciado ou excluído. Por exemplo, se o endereço usado pela última vez estiver distante do endereço de registro (mais outras métricas), então eu excluiria a conta por simplesmente ter um cheiro ruim. Mas o pop-up que mostra as informações do IP não mostra uma localização. Isso é um bug ou devo verificar o MaxMind novamente?
Recebo notificações de devolução em meu endereço postmaster@ - é assim que sei que os e-mails do fórum estão sendo devolvidos. Alguém pode sugerir que eu verifique a Pontuação de Devolução para cortes automáticos para evitar enviar e-mails para alguém que já registrou devoluções. Não temos dados de devolução para pontuação, não configurei o Discourse para consultar POP3 (IMAP??) para tais dados. Tudo o que vejo nos metadados são anedotas do fórum sobre como configurá-lo. Existe uma documentação dedicada real sobre este tópico?
Novamente, tudo isso é apenas para compartilhar a experiência de usuário (não tão boa) nesta área específica, para quem possa estar interessado.
Ainda não configurei o limite de pontuação de rejeição porque não tenho o Discourse verificando e-mails para notificações de rejeição. As informações neste tópico do meta são as melhores que encontrei sobre o assunto de configurar para processar rejeições. Nos próximos dias, estou em busca de documentação mais completa.
Mas sim, hoje estou definindo um limite de rejeição muito baixo.
{“translation”: “[quote="Architect, post:6, topic:323151"] Deve haver uma razão escolhida ou escrita antes que seja possível silenciar a conta.[/quote]\n\nIsso faz sentido porque há uma mensagem no site enviada ao usuário para informá-lo sobre o evento. Essa mensagem do site não é clara sobre o que exatamente queremos que o usuário faça. Então, após a mensagem ser enviada, eu posto uma resposta a essa mensagem para o usuário, pedindo que eles respondam quando tiverem corrigido a situação do e-mail.\n\nOs desafios de iniciante que eu encontro agora incluem:\n\n- Eu quero essa mensagem para o usuário, mas prefiro modificar o texto. Alterar admin/customize/email_templates/system_messages.email_revoked para o inglês não muda para todos os outros idiomas. Ou há uma funcionalidade para rodar uma tradução automática em uma ou todas as mensagens do sistema?\n- Sem uma pesquisa em admin/customize/email_templates/, é difícil encontrar o texto correto nas mensagens do sistema ou notificações de usuário para editar, e também saber quais processos os acionam.\n- Não quero enviar um e-mail quando o problema, por definição, é que eles não estão recebendo e-mails.\n- Quando posto essa resposta na mensagem do sistema no perfil do usuário deles, outro e-mail é enviado. Se pudermos bloquear efetivamente os e-mails enviados, isso não acontecerá. Ou seja, todas as funções de envio de e-mails saem por um processo central que primeiro verifica se o limite de rejeições foi excedido? Ou estou perdendo alguma funcionalidade em torno do Silêncio que bloqueia o envio de e-mails sem precisar vincular essa decisão ao limite de rejeições?\n- Idealmente, quando o usuário substitui o endereço de e-mail por algo válido, ou clica na opção “meu endereço está OK agora”, seria legal o servidor enviar um e-mail de teste e, em caso de sucesso, limpar a bandeira/contagem de rejeição.\n- (Aleatório) Existem um número fixo de razões de suspensão de usuário em admin_js.admin.user.suspend_reasons e elas estão “hard” identificadas para impedir personalização para outro propósito. Ou seja, podemos alterar o texto de admin_js.admin.user.suspend_reasons.combative e há um único admin_js.admin.user.suspend_reasons.custom, mas não parece possível criar uma nova admin_js.admin.user.suspend_reasons.bouncing_email.\n\nEsse cenário não se aplica apenas às rejeições. Posso pensar em outros cenários onde queremos notificar o usuário com uma mensagem local dizendo que não podemos enviar e-mails para ele e dar uma mensagem personalizada armazenada que informe o que fazer.\n\nSuspeito que tudo isso descreve um comportamento muito ajustado que provavelmente não aparece na lista de prioridades, mas ainda não sei se ou como outros lidam com isso. Obrigado pela paciência…”}
Apenas mantendo este tópico atualizado com o progresso…
Acabei de encontrar esta documentação para configurar o tratamento de rejeições:
As imagens aqui também são extremamente úteis:
A implementação desta funcionalidade deve resolver desafios suficientes aqui para lidar com e-mails rejeitados de forma eficaz. Ainda preciso descobrir exatamente como notificaremos uma base de usuários multilíngue de forma eficaz e os colocaremos de volta nos trilhos rapidamente quando eles tiverem corrigido problemas de e-mail. Ou seja, quando eles fizeram uma alteração eficaz, eles precisam nos notificar ou ao sistema para que os bloqueios sobre eles possam ser removidos.
Quando um endereço de e-mail está retornando e-mails automatizados do Discourse, isso parece que você não precisaria/quereria silenciar ou excluir a conta para isso, a menos que você suspeite que seja uma conta falsa ou algo sem e-mail válido.
Acho que esse é provavelmente o motivo pelo qual você gostaria de colocar a conta em espera temporariamente para validar que eles têm um e-mail funcionando, você tem um alto volume de casos assim ou é prático lidar com eles um por um manualmente?
Existem algumas outras opções, como alterar manualmente as configurações de notificação por e-mail, ou alterar temporariamente o endereço de e-mail que não funciona para outro endereço que funcione e seja controlado pelo administrador ou algo assim. Essa pode não ser a melhor ideia, apenas algumas ideias aleatórias aqui.
Quando uma conta é excluída, ela não envia notificação por e-mail sobre isso da última vez que verifiquei. Uma política simples, mas um tanto brutal, é excluir contas se elas não tiverem um e-mail funcionando.
Estamos na mesma página. Existem cenários diferentes que gerentes diferentes vão querer lidar de formas distintas. Estou explorando este software para entender o que ele faz, como ele deve ser usado e como outros o utilizam.
O objetivo subjacente desta iniciativa/investigação é duplo: Primeiro, evitar proativamente o abuso. Segundo, evitar o envio de e-mails que retornem, o que pode resultar em nosso site ser sinalizado como fonte de e-mails não entregáveis. Isso pode resultar em listagens temporárias em RBLs e eu quero evitar esse tipo de bobagem.
Não temos um alto volume para este site, mas existem grupos de usuários, semelhantes, mas diferentes do TL0-4. Usuários em um grupo não devem ser silenciados se algo der errado com o e-mail deles. Usuários em outro grupo com algumas postagens recentes sobre o tópico não devem ser silenciados. Contas sem atividade ou sem atividade válida recente podem ser silenciadas para chamar a atenção deles caso voltem.
O conceito de silenciar pessoas para chamar a atenção delas é estranho. E eu realmente não me importo com endereços de e-mail. A intenção real é que, se tivermos um endereço de e-mail falso, sinto que uma conta tem mais probabilidade de ser uma fonte de abuso do que não. Então, eu os silenciarei preventivamente, buscarei alguma resposta e, se não ouvirmos deles por um longo período, simplesmente excluirei a conta. Um usuário participante (TL1?) do qual simplesmente não ouvimos falar há muito tempo pode ser colocado em silêncio/revisão de longo prazo.
Já que estamos aqui, tudo isso também implica que as pessoas estão criando contas sem um e-mail válido, ou mudando seus endereços para algo inválido. Estou revisando a Documentation e quero criar uma automação para: Silenciar novos usuários TL0 até que eles tenham visualizado alguns tópicos, então enviar um e-mail para eles. Se recebermos um retorno desses e-mails específicos, colocá-los em status de revisão. Portanto, nenhum e-mail de boas-vindas até termos certeza de que são humanos se movendo pelo site, e nenhuma permissão até termos certeza de que eles verificam seu e-mail.
Para sua informação, não é possível ativar sua conta sem antes verificar seu e-mail (a menos que seja ativada manualmente por um administrador, ou você esteja usando SSO e não verificando com seu idp).
Isso não é necessariamente verdade, existem outras razões, como o e-mail pode ser desativado temporariamente, ou eles baniram seu remetente (o que também pode ser temporário, como um silenciamento temporário da conta).
O primeiro passo que eu recomendaria para o que você está descrevendo seria enviar um PM regular para um usuário se o e-mail dele não estiver recebendo mensagens como um alerta sobre isso, caso ele não esteja ciente. Você pode torná-lo um PM de aviso oficial com a caixa de seleção para tornar o ícone de alerta do envelope vermelho em vez de verde. Isso também coloca uma nota na conta deles de que eles receberam um ou vários PMs de aviso oficiais, então você terá isso documentado.
Conforme mencionado com as configurações padrão, novas contas devem ser validadas clicando no link no e-mail de verificação primeiramente antes que possam usar seu site, a menos que você tenha contornado isso.
Isso parece estar basicamente já habilitado com as configurações padrão, embora TL0 possa postar respostas/tópicos públicos, eles não podem enviar mensagens PM para ninguém até serem promovidos para o nível básico TL1, o que requer alguma leitura e o e-mail precisaria ser validado antes disso.
