Redefinir configuração de categorias padrão de visualização

Olá,

Estou tentando redefinir as categorias padrão de acompanhamento para todos os usuários, mas sem sucesso.
Embora pareça que nenhuma categoria foi selecionada na área de configurações, as preferências dos usuários têm algumas categorias selecionadas.

2 curtidas

Olá @ufukayyildiz

Você descobriu como proceder com este problema? Enquanto fazia o mesmo, tive alguns problemas também. Acabou não funcionando nada ^^ c.f. Members not receiving emails from Watched category (again)

3 curtidas

Não, ainda não.

2 curtidas

Acredito que foi projetado para que a configuração respeite as escolhas do usuário. Assim, se um usuário adicionar manualmente uma categoria, ela não será substituída.

Você pode conseguir algo pelo console do Rails, mas acho que uma abordagem melhor seria educar seus usuários. O que você acha? Ou você tem uma situação específica em que precisa alterar o padrão, não importa o quê?

1 curtida

Obrigado pela sua resposta.

Ficaria muito feliz com um comando de console Rails para copiar as preferências do usuário. Entendo perfeitamente a escolha de design de que as preferências do usuário têm prioridade sobre as configurações do site. Mas o problema é que os sites estão evoluindo e sua organização com eles.

No nosso caso, mudamos de uma organização onde todos os anúncios são postados como um novo tópico: o resultado foi uma enorme quantidade de tópicos não discutidos (apenas 1 postagem) na página inicial. Agora vejo que comecei a investigar esse caso em fevereiro de 2023 Unlist or archive a post when it has no reply per category.

Como esses anúncios são relevantes e contêm prazos, não foi uma opção escondê-los da página inicial. Então, mudamos para uma organização com 5 tópicos dedicados (tipo de anúncio) nos quais cada postagem é um novo anúncio.[1] Ainda assim, como essas postagens são importantes, tentamos definir a categoria como “observada” para que os usuários recebam notificações em tempo real.

Este foi o início da situação que resultou atualmente em ninguém recebendo nada, exceto user_mentioned e digest. A mudança teria sido muito mais fácil se fosse possível simplesmente redefinir todas as preferências do usuário para os novos padrões do site. Ou, como outra ideia, copiar as preferências do usuário de um novo cadastro virtual para todos os outros usuários.[2]

Enquanto isso, informei aos usuários sobre o fato de que os sistemas às vezes não funcionam como pretendido e que os e-mails de notificação não virão por um período indefinido.


  1. Aqui seria muito útil poder habilitar apenas “Responder ao Tópico”. ↩︎

  2. Que imagino que seja atualmente possível via rails. ↩︎

Olá novamente. Ainda estou analisando isso e, no nosso caso, redefinir as preferências do usuário faz sentido porque a estrutura do site mudou, o que levou a uma alteração na forma como as notificações por e-mail funcionam.

Da IA do Discourse, recebi a sugestão do seguinte comando Rails:

UserOption.update_all(email_digests: true, email_level: 1, email_messages_level: 1)

Você acha que isso alcançaria o que estamos procurando?
Obrigado!

Acho que os passos abaixo resolveram o problema!

Nas configurações do site, defini a categoria (31) para ser observada por padrão, retroativamente.
Verificar:

CategoryUser.where(category_id: 31).pluck(:user_id, :notification_level)

A maioria dos usuários tem um notification_level de 3 para minha categoria 31. :+1:

Agora há duas coisas no caminho para que esta mudança tenha um efeito de 100%:

  1. As preferências globais de e-mail do usuário.
  2. As preferências de notificação do usuário para cada tópico na categoria (31).

:warning: As linhas a seguir modificarão as configurações pessoais dos seus usuários. Não entre em uma briga.

Primeiro, para “reativar” os e-mails dos usuários, é preciso definir o email_level dos usuários como 1 (ou seja, “quando ausente”) ou 2 (“sempre”):

UserOption.update_all(email_level: 1)

Verificar:

UserOption.group(:email_level).count

Eu obtenho algo como => {1=>X} com X sendo o número de usuários.

Segundo, o notification_level do tópico tem prioridade sobre o notification_level da categoria (que foi modificado nas configurações do site). A maneira mais fácil é remover as preferências do tópico do caminho. Para fazer isso, basta excluir as entradas tópico por tópico:

TopicUser.where(topic_id: <nr_do_tópico>).destroy_all

Verificar:

TopicUser.where(topic_id: <nr_do_tópico>).exists?

Obtendo algo como => [ ] o que significa que nenhum usuário tem preferências de tópico e o notification_level da categoria será o padrão para todos os usuários.


N.B.: De alguma forma, alguns usuários ainda não tinham preferências de notificação para a categoria (31) definidas (ou seja, nenhuma entrada na tabela category_user). Para garantir que seu notification_level esteja definido, é preciso criar uma entrada com o valor para notification_level:

User.find_each do |user|
  unless CategoryUser.exists?(user_id: user.id, category_id: 31)
    CategoryUser.create!(user_id: user.id, category_id: 31, notification_level: 3)
  end
end

Verificar:

CategoryUser.where(category_id: 31).pluck(:id, :notification_level)