أعتقد أن الخطوات أدناه حلت المشكلة!
في إعدادات الموقع، قمت بتعيين الفئة (31) لتكون مراقبة افتراضيًا، بأثر رجعي.
تحقق من:
CategoryUser.where(category_id: 31).pluck(:user_id, :notification_level)
معظم المستخدمين لديهم notification_level بقيمة 3 لفئتي 31. ![]()
الآن هناك شيئان يعيقان هذا التغيير من أن يكون له تأثير بنسبة 100٪:
- التفضيلات العامة للبريد الإلكتروني للمستخدم.
- تفضيلات إشعارات المستخدم لكل موضوع في الفئة (31).
الأسطر التالية ستعدل الإعدادات الشخصية لمستخدميك. لا تدخل في معركة.
أولاً، من أجل “إعادة تنشيط” رسائل البريد الإلكتروني للمستخدم، يجب تعيين email_level للمستخدمين إلى 1 (أي “عند الابتعاد”) أو 2 (“دائمًا”):
UserOption.update_all(email_level: 1)
تحقق من:
UserOption.group(:email_level).count
أحصل على شيء مثل => {1=>X} حيث X هو عدد المستخدمين.
ثانياً، notification_level للموضوع له الأولوية على notification_level للفئة (الذي تم تعديله في إعدادات الموقع). أسهل طريقة هي إزالة تفضيلات الموضوع من الطريق. للقيام بذلك، يقوم المرء ببساطة بحذف الإدخالات موضوعًا تلو الآخر:
TopicUser.where(topic_id: <nr_topic_id>).destroy_all
تحقق من:
TopicUser.where(topic_id: <nr_topic_id>).exists?
أحصل على شيء مثل => [] مما يعني أنه لا يوجد مستخدم لديه تفضيلات موضوع، وسيكون notification_level للفئة هو الافتراضي لجميع المستخدمين.
ملاحظة: بطريقة ما، لا يزال بعض المستخدمين لا يملكون تفضيلات إشعارات للفئة (31) (أي لا يوجد إدخال في جدول category_user). للتأكد من تعيين notification_level الخاص بهم، يجب إنشاء إدخال بالقيمة 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
تحقق من:
CategoryUser.where(category_id: 31).pluck(:id, :notification_level)