Restablecer la configuración predeterminada de categorías de visualización

Hola,

Estoy intentando restablecer las categorías predeterminadas que se están observando para todos los usuarios, pero sin éxito.

Aunque parece que no hay categorías seleccionadas en el área de configuración, las preferencias de los usuarios tienen algunas categorías seleccionadas.

2 Me gusta

Hola @ufukayyildiz

¿Descubriste cómo proceder con este problema? Mientras hacía lo mismo, también tuve algunos problemas. Al final no funcionó en absoluto ^^ c.f. Members not receiving emails from Watched category (again)

3 Me gusta

No, todavía no.

2 Me gusta

Creo que está diseñado para que la configuración respete las elecciones del usuario. Por lo tanto, si un usuario agrega manualmente una categoría, no se sobrescribirá.

Es posible que pueda hacer algo desde la consola de Rails, pero creo que un mejor enfoque sería educar a sus usuarios. ¿Qué piensa? ¿O tiene una situación específica en la que se le exige cambiar el valor predeterminado sin importar qué?

1 me gusta

Gracias por tu respuesta.

Estaría muy contento con un comando de consola de Rails para copiar las preferencias del usuario. Entiendo perfectamente la elección de diseño de que las preferencias del usuario tengan prioridad sobre la configuración del sitio. Pero el problema es que los sitios evolucionan y su organización con ellos.

En nuestro caso, cambiamos de una organización donde todos los anuncios se publican como un nuevo tema: el resultado fue una gran cantidad de temas no discutidos (solo 1 publicación) en la página principal. Ahora veo que comencé a investigar ese caso en febrero de 2023 Unlist or archive a post when it has no reply per category.

Dado que estos anuncios son relevantes y contienen plazos, no fue una opción ocultarlos de la página principal. Así que pasamos a una organización con 5 temas dedicados (tipo de anuncio) en los que cada publicación es un nuevo anuncio.[1] Aún así, dado que estas publicaciones son importantes, intentamos configurar la categoría como vigilada para que los usuarios reciban notificaciones en tiempo real.

Este fue el comienzo de la situación que actualmente resulta en que nadie recibe nada excepto user_mentioned y digest. El cambio habría sido mucho más fácil si se pudieran restablecer todas las preferencias del usuario a los nuevos valores predeterminados del sitio. O, como otra idea, copiar las preferencias del usuario de un registro virtual nuevo a todos los demás usuarios.[2]

Mientras tanto, les informé a los usuarios sobre el hecho de que los sistemas a veces no funcionan como se esperaba y que los correos electrónicos de notificación no llegarán por un período de tiempo indefinido.


  1. Aquí sería muy útil poder habilitar solo “Responder al tema”. ↩︎

  2. Lo que me imagino que actualmente es posible a través de Rails. ↩︎

Hola de nuevo. Todavía estoy investigando esto y, en nuestro caso, restablecer las preferencias del usuario tiene sentido porque la estructura del sitio ha cambiado, lo que ha provocado un cambio en la forma en que funcionan las notificaciones por correo electrónico.

De la IA de Discourse, me sugirieron el siguiente comando de Rails:

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

¿Crees que esto lograría lo que buscamos?
¡Gracias!

¡Creo que los pasos a continuación resolvieron el problema!

En la configuración del sitio, establecí la categoría (31) para que se observara por defecto, retroactivamente.
Verificar:

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

La mayoría de los usuarios tienen un notification_level de 3 para mi categoría 31. :+1:

Ahora hay dos cosas que impiden que este cambio tenga un efecto del 100%:

  1. Las preferencias de correo electrónico globales del usuario.
  2. Las preferencias de notificación del usuario para cada tema en la categoría (31).

:warning: Las siguientes líneas modificarán la configuración personal de sus usuarios. No se pelee.

Primero, para “reactivar” los correos electrónicos del usuario, uno tiene que establecer el email_level del usuario en 1 (es decir, “cuando esté ausente”) o 2 (“siempre”):

UserOption.update_all(email_level: 1)

Verificar:

UserOption.group(:email_level).count

Obtengo algo como => {1=>X} donde X es el número de usuarios.

Segundo, el notification_level del tema tiene prioridad sobre el notification_level de la categoría (que se modificó en la configuración del sitio). La forma más fácil es eliminar las preferencias del tema. Para hacerlo, simplemente se eliminan las entradas tema por tema:

TopicUser.where(topic_id: <nr_del_tema>).destroy_all

Verificar:

TopicUser.where(topic_id: <nr_del_tema>).exists?

Obtengo algo como => [] lo que significa que ningún usuario tiene preferencias de tema y el notification_level de la categoría será el predeterminado para todos los usuarios.


N.B.: De alguna manera, algunos usuarios todavía no tenían preferencias de notificación para la categoría (31) configuradas (es decir, ninguna entrada en la tabla category_user). Para asegurarse de que su notification_level esté configurado, uno tiene que crear una entrada con el 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)