Salut,
J’essaie de réinitialiser les catégories par défaut suivies pour tous les utilisateurs, mais sans succès.
Bien qu’il semble qu’aucune catégorie ne soit sélectionnée dans la zone des paramètres, les préférences des utilisateurs ont certaines catégories sélectionnées.
Bonjour @ufukayyildiz
Avez-vous trouvé comment procéder pour ce problème ? En faisant la même chose, j’ai eu quelques difficultés également. Cela n’a finalement pas fonctionné du tout ^^ cf. Members not receiving emails from Watched category (again)
Non, pas encore.
Je pense que c’est conçu pour que le paramètre respecte les choix de l’utilisateur. Ainsi, si un utilisateur ajoute manuellement une catégorie, elle ne sera pas écrasée.
Vous pourriez peut-être faire de la magie depuis la console Rails, mais je pense qu’une meilleure approche serait d’éduquer vos utilisateurs. Qu’en pensez-vous ? Ou avez-vous une situation spécifique dans laquelle vous êtes obligé de changer le défaut quoi qu’il arrive ?
Merci pour votre réponse.
Je serais très heureux d’avoir une commande de console Rails pour copier les préférences utilisateur. Je comprends tout à fait le choix de conception selon lequel les préférences utilisateur priment sur les paramètres du site. Mais le problème est que les sites évoluent et leur organisation avec eux.
Dans notre cas, nous sommes passés d’une organisation où toutes les annonces sont publiées sous forme de nouveau sujet : le résultat a été une énorme quantité de sujets non discutés (1 seul message) sur la page d’accueil. Je vois maintenant que j’ai commencé à examiner ce cas en février 2023 Unlist or archive a post when it has no reply per category.
Comme ces annonces sont pertinentes et contiennent des délais, ce n’était pas un choix de les cacher de la page d’accueil. Nous avons donc opté pour une organisation avec 5 sujets dédiés (type d’annonce) dans lesquels chaque message est une nouvelle annonce.[^1] Toujours comme ces messages sont importants, nous avons essayé de définir la catégorie sur « surveillée » afin d’alerter les utilisateurs en temps réel.
Ce fut le début de la situation qui fait qu’actuellement personne ne reçoit rien, sauf user_mentioned et digest. Le changement aurait été tellement plus facile si l’on pouvait simplement réinitialiser toutes les préférences utilisateur aux nouveaux paramètres par défaut du site. Ou, comme autre idée, copier les préférences utilisateur d’une inscription virtuelle de nouveau membre à tous les autres utilisateurs.[^2]
Entre-temps, j’ai informé les utilisateurs du fait que les systèmes ne fonctionnent parfois pas comme prévu et que les e-mails de notification ne seront pas envoyés pendant une période indéfinie.
[^1] : Il serait très utile ici de pouvoir activer uniquement la fonction « Répondre au sujet ».
[^2] : Ce qui, je peux l’imaginer, est actuellement possible via Rails.
Bonjour. Je continue d’examiner la question et, dans notre cas, réinitialiser les préférences utilisateur est logique car la structure du site a changé, ce qui a entraîné une modification du fonctionnement des notifications par e-mail.
D’après Discourse AI, on m’a suggéré la commande Rails suivante :
UserOption.update_all(email_digests: true, email_level: 1, email_messages_level: 1)
Pensez-vous que cela atteindrait ce que nous recherchons ?
Merci !
Je pense que les étapes ci-dessous ont résolu le problème !
Dans les paramètres du site, j’ai défini la catégorie (31) comme étant à suivre par défaut, de manière rétroactive.
Vérifier :
CategoryUser.where(category_id: 31).pluck(:user_id, :notification_level)
La plupart des utilisateurs ont un notification_level de 3 pour ma catégorie 31. 
Il y a maintenant deux obstacles à l’effet complet de ce changement :
Les lignes suivantes modifieront les paramètres personnels de vos utilisateurs. Ne vous disputez pas.
Premièrement, afin de « réactiver » les e-mails des utilisateurs, il faut définir le email_level des utilisateurs à 1 (c’est-à-dire « quand absent ») ou 2 (« toujours ») :
UserOption.update_all(email_level: 1)
Vérifier :
UserOption.group(:email_level).count
J’obtiens quelque chose comme => {1=>X} où X est le nombre d’utilisateurs.
Deuxièmement, le notification_level du sujet a la priorité sur le notification_level de la catégorie (qui a été modifié dans les paramètres du site). Le moyen le plus simple est de supprimer les préférences du sujet. Pour ce faire, il suffit de supprimer les entrées sujet par sujet :
TopicUser.where(topic_id: <numéro_du_sujet>).destroy_all
Vérifier :
TopicUser.where(topic_id: <numéro_du_sujet>).exists?
J’obtiens quelque chose comme => [ ] ce qui signifie qu’aucun utilisateur n’a de préférences de sujet et que le notification_level de la catégorie sera le défaut pour tous les utilisateurs.
N.B. : D’une manière ou d’une autre, certains utilisateurs n’avaient toujours pas de préférences de notification pour la catégorie (31) définies (c’est-à-dire aucune entrée dans la table category_user). Pour s’assurer que leur notification_level est défini, il faut créer une entrée avec la valeur pour 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
Vérifier :
CategoryUser.where(category_id: 31).pluck(:id, :notification_level)