Nous disposons d’une catégorie « Inapproprié » où les modérateurs peuvent déplacer les publications signalées, afin qu’elles puissent toujours être discutées même si elles ne conviennent pas à notre forum public. Nous ne souhaitons évidemment pas que cette catégorie soit incluse dans les e-mails de résumé, et elle avait été supprimée dans les paramètres du site :
Cependant, un sujet provenant de cette catégorie a été inclus dans notre dernier résumé. J’ai désélectionné puis resélectionné l’option dans les paramètres et j’ai constaté une modification dans le journal :
14 est l’identifiant de la catégorie Inapproprié. La catégorie Précédente2 (probablement « Retour sur le site ») avait été supprimée il y a longtemps, mais apparemment, elle figurait toujours dans la liste des catégories supprimées. Cela pourrait-il être un bug ayant empêché la liste de fonctionner comme prévu ?
Oui, je viens de tester cela sur mon site de développement local et je constate la même chose. Je pense que le problème vient de la logique utilisée ici :
Modifier cette ligne en topics = topics.where("topics.category_id NOT IN (?)", remove_category_ids) semble résoudre le problème avec les catégories ajoutées au paramètre digest_suppress_categories, mais il faudra ajouter une logique pour gérer les catégories mises en sourdine. Peut-être quelque chose comme :
topics = topics.where("topics.category_id NOT IN (?)", remove_category_ids).where("topic_users.notification_level != (?)", TopicUser.notification_levels[:muted])
Je pense que le problème vient du fait que l’utilisateur cible a déjà visité ce sujet et qu’un enregistrement du modèle TopicUser a été créé pour cet utilisateur. Ainsi, ce sujet satisfait la condition ci-dessus où nous vérifions s’il est désactivé ou non. Dans ce cas, la PR ci-dessous devrait résoudre ce problème.