نعم، عند حذف مستخدم، نقوم بإزالته من أي فعاليات قد قام بتأكيد حضورها. ربما يكون هذا الكود هو السبب في ذلك.
3 إعجابات
لأن جميع معرفات المواضيع في الخطأ هي مواضيع تستخدم ميزة “الأحداث”.
مما لا شك فيه أن هؤلاء المستخدمين المحددين الذين أحذفهم لم يؤكدوا حضورهم، لكن قد يكون السبب هو أن هذه هي المواضيع الوحيدة التي تم تفعيل خيار تأكيد الحضور فيها؟
3 إعجابات
أوه أوه، فهمت.
@fzngagan هل هذا يستخدم .find( غير آمن؟
topics = Topic.find(topic_ids) if topic_ids
انظر إلى التصحيح أعلاه الذي قمت بدفعه للتو إلى Follow (على الرغم من أن الحل هنا قد يحتاج إلى أن يكون مختلفًا نظرًا لوجود عدة معرفات - هل نستخدم where؟)
3 إعجابات
لقد قمت بالتحديث للتو، لكن لا يزال يظهر لي خطأ 404.
إعجاب واحد (1)
بارت، انتظر حتى يقوم @fzngagan بتطبيق التأكيد وإصلاح المشكلة.
5 إعجابات
لقد دفعت إصلاحًا. يُرجى التحقق من ذلك وتأكيد النتيجة.
5 إعجابات
هذا ما أصلح الأمر، شكرًا لك!!
6 إعجابات
لقد رأيت الآن عدة مرات منشورات في قائمة المراجعة بسبب السبب “كتب المستخدم الجديد منشوره الأول بشكل مشبوه بسرعة”.
عند الفحص الدقيق، لاحظت أن هذه المنشورات تحتوي على كلمة مراقبة، لكن لم يُذكر ذلك في قائمة المراجعة.
بما أن التنبيه “كتب المستخدم الجديد منشوره الأول بشكل مشبوه بسرعة” يكون خاطئًا في 96% من الحالات، بينما تكون تنبيهات “الكلمات المراقبة” صحيحة بنسبة 100%، أي إذا دخل منشور إلى قائمة المراجعة بسبب كلمة مراقبة، فهو بنسبة 100% منشور يحتاج حقًا إلى انتباه، فأنا أرى أن “الكلمات المراقبة” يجب أن تسبق “المستخدم الجديد كتب بسرعة كبيرة”.
تخيل الحالات التالية:
- يدخل المنشور إلى قائمة المراجعة بسبب “كتب المستخدم الجديد منشوره الأول بشكل مشبوه بسرعة”. يحتوي هذا المنشور على رابط سبام غير مرئي مدرج في قائمة “الكلمات المراقبة”. → يُوافق على المنشور، لأن أحدًا لا يلاحظ الرابط غير المرئي (مثل رابط مخفي خلف “.”). → فشل!
- يدخل المنشور إلى قائمة المراجعة بسبب كلمة مراقبة (بأولوية “الكلمات المراقبة” على “كتب بسرعة كبيرة”). يحتوي هذا المنشور على رابط سبام غير مرئي مدرج في قائمة “الكلمات المراقبة”. → يُرفض المنشور ويُحذف المرسل السبام بسبب “الكلمات المراقبة” → فوز!
5 إعجابات
بالتأكيد، هذا يعتبر عيبًا على الحافة، هل يمكننا إضافته إلى قائمة شخص ما @eviltrout؟ أرى أن @Roman لا يزال مكلفًا بالمهمة، ربما؟
4 إعجابات
تم الإصلاح هنا:
8 إعجابات
في الإصدار 2.6.0.beta2. مجرد تنبيه، لدي مواضيع في قائمة الانتظار تبدو وكأنها تم حذفها. لذا أعتقد أن طريقة حدوث هذا الأمر تشبه ما يلي:
- يتم وضع مشاركة المستخدم في قائمة المراجعة بسبب الكتابة السريعة.
- يقوم المستخدم بحذف موضوعه (إذا كان ذلك ممكنًا)، ربما لإعادة تقديمه.
غير متأكد مما إذا كان هذا مقصودًا أم لا. في قائمة المراجعة، يكون العنوان فارغًا، لكن جسم المشاركة موجود، وقد تم إسكات المستخدم. لا يمكنني رؤية أي مواضيع/مشاركات في الملف الشخصي العام للمستخدم.
غير مرتبط بما سبق. لدي اقتراح لخيارات التصفية. ميزة ستكون رائعة جدًا برأيي، وهي تصفية أكثر تفصيلاً لأنواع المشاركات/المواضيع. حاليًا، بالنسبة للأنواع لدينا:
تشمل “المشاركة المرفوضة” و"المشاركة في قائمة الانتظار" كلاً من المواضيع والمشاركات. أعتقد أنه سيكون مفيدًا جدًا إذا تم تغيير ذلك إلى ما يلي فقط:
نوع المراجعة:
- مرفوض
- في قائمة الانتظار
يمكن أيضًا النظر في تقسيم “المرفوض” إلى “مرفوض من قبل المستخدم” و"مرفوض من قبل النظام".
ثم إضافة فلتر آخر لنوع المحتوى.
نوع المحتوى:
- موضوع
- مشاركة
- مستخدم
أعتقد أن هذا سيكون مفيدًا جدًا. يمكن أن يكون سريعًا جدًا لتحديد أولوية الموافقة على المواضيع قبل الموافقة على المشاركات/الردود مثلًا. لا توجد طريقة حقيقية للتمييز بين المواضيع والمشاركات مع الفلاتر الحالية بخلاف “مجموعة حسب الموضوع”.
اقتراح آخر هو تعديل واجهة مستخدم قائمة المراجعة بحيث يكون من السهل التمييز بين المواضيع والمشاركات. حاليًا، يتم عرض هذه المعلومات كنص رمادي صغير (أي: مشاركة في قائمة الانتظار، موضوع في قائمة الانتظار، مشاركة مرفوضة، موضوع مرفوض). حجم النص هو نفس حجم فئات الموضوع/المشاركة وعلاماتها.
بالنسبة لي، ليس من الواضح على الفور ما إذا كان العنصر موضوعًا أم مشاركة/ردًا، وأخلط بينهما بشكل متكرر.
بعض الأفكار:
- تعديل قسم عنوان الموضوع في عناصر المشاركة لإضافة أيقونة رد وجعلها أصغر مما هي عليه لعناصر الموضوع، وربما تضمين النص RE:
- زيادة حجم النص/التأكيد على نوع العنصر (موضوع/مشاركة).
إعجابَين (2)
عند محاولة الموافقة على المواضيع والمشاركات، أحصل على خطأ 500. أنا أستخدم حاليًا الإصدار 2.6.0.beta3. إليك سجل الأخطاء:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
من المعلومات ذات الصلة المحتملة أنني كنت قد قمت بتثبيت Akismet سابقًا ثم أزلته (وقمت أيضًا بتشغيل مهمة Rake) كما هو مفصل هنا: Feedback on the new Review Queue (2019) - #210 by markersocial
البنود تعود إلى آخر 60 يومًا (auto_handle_queued_age: 60). لقد جربت ذلك مع مشاركات قديمة (منذ حوالي شهرين) ومشاركات حديثة (خلال آخر 3 ساعات).
أستطيع الموافقة على المستخدمين (النوع: مستخدم) وتعمل خيار ‘حذف المستخدم’ للمواضيع/المشاركات المعلقة.
إعجابَين (2)
@Roman هذا غريب جداً - كيف حصلنا على عدد صحيح ضخم هنا؟
6 إعجابات
يتم إلقاء الخطأ عند محاولة إنشاء إشعار:
أعتقد أننا ربما نقوم بتخزين
ربما نقوم بتخزين بعض المعرفات باستخدام نوع int؟ بدأ Rails في استخدام BIGINT(8) للمفاتيح الأساسية في الإصدار 5.1.
@markersorcial هل يمكنك مشاركة نتائج هذه الاستعلامات معنا؟
Notification.count
User.count
Topic.count
4 إعجابات
شكرًا لك على الاطلاع على هذا 
بالتأكيد، إليك نتائج الاستعلام:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
3 إعجابات
تحديث: أثناء فحص Sidekiq، أرى العديد من المهام الفاشلة مع هذا الخطأ الذي يبدو مشابهاً:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
بالنسبة لأنواع المهام هذه (التي لاحظتها حتى الآن):
Jobs::PostAlert (الأكثر شيوعاً)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
إعجاب واحد (1)
لا ينبغي أن تتجاوز أي من هذه الأرقام الحد الأقصى للحجم. أتساءل عما إذا كان هناك شيء آخر يقوم بكتابة قيمة صحيحة فوق قيمتها @Roman.
3 إعجابات
إذن يجب أن يكون هناك شيء آخر. هناك بالتأكيد مشكلة ما، وهي ليست محددة في قائمة مراجعات الموضوعات.
تقوم هذه الوظائف بإنشاء إشعارات وهي تفشل أيضًا:
أيضًا، إذا حاولت فعل شيء مثل هذا:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
فأنا أحصل على خطأ مختلف:
ActiveModel::RangeError: الرقم 1311344111111 خارج النطاق المسموح به لـ ActiveModel::Type::Integer الذي له حد 4 بايت
حصلت على نفس الخطأ عند تنفيذ هذا:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
6 إعجابات
@markersocial أتساءل عما إذا كانت سجلات PostgreSQL يمكن أن تساعدنا في الحصول على مزيد من المعلومات حول الخطأ. هل يمكنك التحقق من ذلك من فضلك؟
إذا لم تكن تعرف أين تجد السجلات، فراجع:
5 إعجابات
يقدر مشرفونا القدرة على مناقشة المنشورات المحددة بسهولة فيما بينهم مع الاحتفاظ بالسجل في قائمة المراجعة. هل من الممكن إضافة نفس القدرة إلى المنشورات المعلقة؟ نستخدم إعداد approve_post_count لطلب الموافقة على أول 5 منشورات لمستخدم جديد. تصبح هذه المنشورات الخمسة الأولى منشورات معلقة، ولكن إذا تطلبت مناقشة من قبل المشرفين، فيجب عليهم بدء رسالة خاصة منفصلة عن قائمة المراجعة، مما يؤدي إلى فقدان السجل.
3 إعجابات