Notei em Admin|Emails|Enviados que um e-mail de resumo não foi enviado aos usuários, mas todos eles receberam um e-mail para user_watching_first_post (conforme uma configuração padrão predefinida).
Verifiquei que não é o caso de esses usuários terem visitado recentemente, estarem além da configuração “suprimir e-mail de resumo após dias” ou terem alterado suas preferências de e-mail.
Está correto que um e-mail de notificação é tratado como atividade do usuário, fazendo com que o resumo seja pulado? Se sim, não é o comportamento que eu esperava…
Estamos usando “assistir ao primeiro post” para uma tag específica para notificar os usuários sobre tópicos de alta prioridade, mas ainda queremos que eles recebam o resumo regular de outras atividades do fórum.
Isso é bastante central para nossa visão — agradeceria qualquer contribuição sobre como fazer isso acontecer.
Então, o caso é que receber uma notificação por e-mail sobre um tópico impede que o tópico apareça no resumo? Faz sentido que você não queira receber no resumo uma mensagem que já recebeu por e-mail de outra forma.
É muito mais do que isso. Receber uma notificação por e-mail parece redefinir completamente a contagem, de modo que nenhum tópico mais antigo que a notificação seja incluído no resumo. Isso sempre me incomodou.
Basicamente, se o usuário notificado por e-mail não visitar o site, não haverá nenhuma exposição de tópicos entre o resumo anterior e a última notificação por e-mail. E isso faz com que o site pareça muito mais quieto do que realmente é quando um resumo finalmente aparece.
Eu gostaria de ver isso como você sugere, onde apenas os tópicos notificados são suprimidos no resumo para usuários que recebem uma notificação por e-mail, mas não visitam o site. Isso seria uma grande melhoria para sites que fazem bastante observação padrão!!
Obrigado por confirmar, Nathan. Sim, um resumo não foi enviado apesar de outros tópicos elegíveis novos.
Se o resumo apenas evitasse duplicar o tópico de outra forma notificado, faria sentido, mas o que ele está fazendo realmente parece uma falha ou um bug que é bastante contraproducente.
@pfaffman - isso parece uma regra que poderia ser modificada de alguma forma? Ou precisaria da atenção dos desenvolvedores?
Seria necessário um plugin. Eu escrevi um uma vez que, pelo menos em uma época, se propunha a “adicionar o número de novas postagens ao e-mail de resumo/digest na 3ª posição (geralmente onde estão os novos usuários)”. Então, ele muda apenas esse cabeçalho no topo da página.
Ele substitui todo esse template, então essa é uma solução potencial.
Após pensar melhor, isso realmente parece um bug e não algo para contornar com um plugin. Tenho que acreditar que o comportamento não é intencional.
Site_settings inclui opções para suprimir o resumo, mas nenhuma se relaciona a outras notificações por e-mail:
suprimir e-mail de resumo após dias
categorias de supressão de resumo
tags de supressão de resumo
Mais importante ainda, a preferência do usuário para E-mails|Resumo de Atividade é: “Quando eu não visito aqui, envie-me um resumo por e-mail dos tópicos populares e respostas.” – Sim ou não, ponto final. Nenhuma relação com e-mails de Rastreamento é indicada.
Com base nessas configurações, os usuários devem esperar que a configuração de Resumo de Atividade se aplique conforme descrito e de forma independente.
Suprimir tópicos notificados do resumo seria ótimo, mas eu consideraria isso um luxo. Apenas tornar o resumo ciente das notificações de e-mail de Rastreamento o traria de acordo com as expectativas.
Estou me aprofundando aqui, mas por curiosidade estou olhando o código no Github…
Na seção de resumo de app/mailers/user_notifications.rb, topics_for_digest são procurados com base em um min_date que considera user.last_emailed_at
linha 227:
min_date = opts[:since] || user.last_emailed_at || user.last_seen_at || 1.month.ago
# Busca alguns tópicos e posts para mostrar
digest_opts = {
limit: SiteSetting.digest_topics + SiteSetting.digest_other_topics,
top_order: true,
}
topics_for_digest = Topic.for_digest(user, min_date, digest_opts).to_a
if topics_for_digest.empty? && !user.user_option.try(:include_tl0_in_digests)
# Busca alguns tópicos de novos usuários que tenham pelo menos 24 horas
topics_for_digest =
Topic
.for_digest(user, min_date, digest_opts.merge(include_tl0: true))
.where("topics.created_at < ?", 24.hours.ago)
.to_a
end
(Edição: Vejo que last_emailed_at também é referenciado em app/jobs/scheduled/enqueue_digest_emails.rb e spec/jobs/enqueue_digest_emails_spec.rb, entre outras coisas.)
Isso me faz pensar que um resumo simplesmente não é gerado para usuários cujo user.last_emailed_at é muito recente.
Não consegui discernir quais e-mails contam para last_emailed_at. Evidentemente, inclui notificações com base nas configurações de Rastreamento, mas e mensagens privadas, etc..?
O resumo não deveria se preocupar apenas com user.last_seen_at?
Atualmente, quando o modo de lista de e-mails está ativado — pelo menos no nível de preferência do usuário (veja a postagem seguinte) — a interface deixa claro que as configurações de resumo são substituídas.
Portanto, talvez a única coisa a adicionar seria um “enviar sempre”, por exemplo:
Resumo da Atividade:
Enviar-me sempre um resumo por e-mail
Enviar-me um resumo por e-mail apenas quando eu não visitar aqui
(Menu suspenso): a cada 30 minutos | a cada hora | diariamente | semanalmente | a cada mês | a cada seis meses
Mas eu veria a opção “sempre” como um “nice-to-have”. Apenas tornar o resumo independente de outros e-mails pareceria fazê-lo funcionar como esperado.
(Nota lateral: se eu tivesse um fórum grande, eu poderia desejar que os períodos de tempo disponíveis fossem configuráveis pelo administrador. Muitas pessoas escolhendo “enviar sempre… a cada 30 minutos” poderiam aumentar os custos de e-mail.)
Isso é secundário ao problema que relatei, mas está relacionado à preocupação de Sam sobre o Modo Lista de E-mails vs. Resumo de Atividades…
Curiosamente, quando o administrador ativa o "modo de lista de e-mails padrão" e "desativar o modo de lista de e-mails" (Cenário A), não está claro o que acontece. O usuário não vê nada sobre o Modo Lista de E-mails e aparentemente ainda pode ativar o Resumo de Atividades e outros e-mails.
As duas configurações de administrador parecem ser independentes, quando talvez haja uma dependência… "proibir que os usuários ativem o modo de lista de e-mails" substitui o "modo de lista de e-mails padrão"?
Cenário A
Configurações do administrador, "lista de e-mails":
No entanto, se o administrador deixar a opção "desativar o modo de lista de e-mails" desmarcada, o usuário verá que foi definido como "Modo de lista de e-mails ativado". Isso parece claro o suficiente.
Cenário B
Configurações do administrador, "lista de e-mails":
Obrigado pela atualização, Sam. Gostaria de ter as habilidades para desenvolver e oferecer um PR.
Dado o número de correções e melhorias nas notas de lançamento, só consigo imaginar como é o backlog. Mas espero que isso mereça atenção – os usuários não têm motivo para suspeitar que o resumo não os manterá atualizados de forma confiável.
Olá @ToddZ — peço desculpas pela falta de comunicação da minha parte. Obrigado por levantar tudo isso.
Concordo com @sam que receber uma notificação não deve contar como uma visita que o impediria de receber um e-mail de resumo de atividades. Trabalharei com a equipe para corrigir isso e retornarei assim que tivermos resolvido esse problema, embora no momento eu não tenha um prazo para compartilhar.
