مرحبًا، أعاني من مشكلة بدأت منذ عدة تحديثات لـ Discourse، حيث أتلقى إشعارات بأن مستخدمًا جديدًا في انتظار الموافقة، لأجد بعد ذلك أن قائمة المراجعة فارغة.
تحدث هذه المشكلة فقط عندما يكون مستخدم واحد هو من يطلب الموافقة. أما إذا كان هناك عدة أشخاص في انتظار الموافقة، فأستطيع رؤية جميعهم في القائمة ما عدا واحدًا — فواحد دائمًا ما يُستبعد.
بعبارة أخرى، لم يتمكن الكثير من الأشخاص من التسجيل.
في موضوع منفصل، اقترح البعض أن إضافة (plugin) التحديد المتعدد قد تكون متورطة بطريقة ما وتسبب في أن يضيف Discourse رقمًا زائدًا إلى طول قائمة الانتظار.
لكن يبدو هذا غير مرجح في المجمل، إذ يجب أن يكون هناك شيء ما يحدث ليشغّل الإشعار في بعض الأيام ولا يحدث في أيام أخرى. كما أن المشكلة لم تبدأ عند تثبيت الإضافة، بل بدأت بعد عدة أشهر، ولا أستطيع ربطها إلا بتحديث لـ Discourse (لأنني لا أعتقد أن أي إضافات أو تغييرات أخرى قد تم إجراؤها منذ ذلك الحين).
هل واجه أي شخص آخر هذه المشكلة؟ وما قد يكون الحل؟
وبالمناسبة، @jjaffeux، هل من الممكن أن يكون التعديل الذي قمت به على هذه الإضافة بعنوان “FIX: makes value parsing more resilient” متورطًا في هذه المشكلة؟
مرحبًا - أنا أيضًا غير واضح، هل يمكن أن يكون الأمر يشمل كلا السببين؟
لم تبدأ المشكلة عند تثبيت الإضافة لأول مرة، بل بدأت منذ عدة تحديثات للنواة. إذا كانت الإضافة متورطة على الإطلاق، فربما يكون هناك تفاعل غير مقصود؟
لا يمكنني حقًا اختبار إلغاء تثبيت الإضافة لمعرفة ما إذا كانت المشكلة ستستمر، لأنها حيوية للغاية - حيث يعتمد فحص تسجيلات المستخدمين على الإجابات التي لا يمكنهم تقديمها إلا مع تفعيل هذه الإضافة (حيث يحتاج المستخدمون إلى اختيار عناصر من قائمة منسدلة).
أعتقد أن توصيتي الأولى هنا هي الانتظار حتى يحدث “الحالة السيئة”… ثم تفعيل وضع الأمان في متصفحك ومعرفة ما إذا كانت الطابور تبدو جيدة.
إذا بدت جيدة في وضع الأمان، فمن المحتمل أنك تريد النشر في قناة Marketplace لتحويل الإضافة إلى مكون سمة (theme component) وتحديثها إلى أحدث الأنماط من Discourse.
للأسف، نفس النتائج في الوضع الآمن — استجابةً لإشعار بالمستخدمين المعلقين، لا يزال هناك مستخدم واحد مفقود من قائمة الانتظار للمراجعة، حتى عند الزيارة في وضع discourse الآمن مع تعطيل جميع عناصر تخصيص الموقع الثلاثة.
حسناً، كان ذلك مثيراً للاهتمام – لقد حاولت استخدام حسابي في Gmail كما هو موضح أعلاه، ولكن حتى أثناء فتح صفحة Gmail الخاصة بي في نافذة متصفح أخرى وانتظار وصول بريد التحقق الذي تولّده Discourse، تم إشعاري عبر عنوان البريد الإلكتروني الإداري العادي الخاص بي بخصوص تسجيل دخول جديد يحتاج إلى مراجعة (وكانت قائمة الانتظار فارغة كما كانت من قبل). لقد أخطأت في كتابة العنوان، لذا لم أستلم البريد الإلكتروني الموجه إلى حساب Gmail الخاص بي، وبالتالي لم أكمل عملية التحقق.
لذا، ما لم يكن هذا مجرد مصادفة، فربما تكون إشعارات المشرفين قد سبقت الأحداث؟ مع ذلك، هذا لا يفسر لماذا تتضمن كل إشعار بالضبط شخصاً واحداً مفقوداً في قائمة الانتظار – فمن المفترض ألا يحدث فشل في التحقق من عنوان البريد الإلكتروني من قبل متقدم واحد فقط دون الباقين دائماً.
** تعديل
بعد ذلك، صحّحت عنوان Gmail الخاص بي في نافذة التسجيل الخاصة بالوضع المتخفي وأعدت إرسال بريد التحقق – والذي ظهر بعد ذلك في نافذة متصفح Gmail الخاصة بي. قمت بالتحقق منه بنجاح باستخدام رابط التحقق في نافذة متخفية أخرى. لم يتم إرسال أي إشعار لاحق إلى عنوان البريد الإلكتروني الإداري الخاص بي، لذا لا يمكنني إلا افتراض أن الإشعار الأول كان مرتبطاً بالفعل بمحاولة التسجيل الجديدة هذه.
باستخدام نافذة متصفح أخرى، قمت بزيارة الموقع مرة أخرى في وضع آمن، وسجلت الدخول كمسؤول، ورأيت نفس قائمة الانتظار التي تحتوي على شخص واحد للمراجعة – ولكن هذه المرة كانت حسابي الاختباري الجديد مرئياً ويمكن الموافقة عليه.
للمتابعة - حاولت مرة أخرى وأنشأت حسابًا وهميًا جديدًا عبر نافذة التصفح المتخفي (مع إدخال العنوان الصحيح من المرة الأولى) - وقد نجحت هذه المحاولة كما هو متوقع، وعند الرد على إشعار المسؤول عبر البريد الإلكتروني من نافذة متصفح عادية، لاحظت ظهور المستخدم الجديد في قائمة الانتظار.
كررت العملية بتسجيل جديد عبر نافذة عادية، وردت على الإشعار عبر نافذة عادية أيضًا (بدون استخدام التصفح المتخفي أو الوضع الآمن في أي مرحلة) - وعملت كل شيء كما يجب مرة أخرى. وبالتالي، فإن المشكلة (أو ربما مشكلتين: إشعار المسؤول حتى قبل التحقق من عنوان البريد الإلكتروني من قبل مقدم الطلب، وعدم ظهور الطلب غير المكتمل أو المكتمل في قائمة الانتظار) كانت مقصورة على المحاولة الأولى فقط.
مرة أخرى، لست متأكدًا مما إذا كان هذا يضيف الكثير من الوضوح، لكن ربما بعد أن يفشل النظام في عملية تسجيل أول (بتوليد إشعار وهمي)، تعمل عمليات التسجيل اللاحقة بشكل صحيح؟ أو ربما يعود النظام إلى وضع الفشل بعد مرور فترة زمنية كافية دون أي نشاط تسجيل جديد؟
أظن أن عملية هجرة أضفتها في نفس الوقت تقريبًا مع الإلتزام الذي ذكرته هي التي تسببت في هذه المشكلة، مما جعل بعض المستخدمين غير المعتمدين يبدون وكأنهم في قائمة المراجعة، مما أدى إلى إشعارات غريبة.
هل يمكنك تشغيل هذا الاستعلام في مستكشف البيانات للتأكد من صحة ذلك؟
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'User' AND r.status = 1 AND users.approved = FALSE
ومع ذلك، فإن تثبيت Discourse الخاص بي لا يُظهر حاليًا أي مستخدمين في حالة انتظار.
لقد أنشأت للتو حسابًا وهميًا آخر، وتم التحقق من عنوانه، لكن لم يتم إرسال أي إشعار على الإطلاق إلى بريد إلكتروني المسؤول الخاص بي. بعد تسجيل الدخول مجددًا إلى موقعي بصفتي مسؤولًا، أعدت تشغيل الاستعلام، وكان العدد صفرًا مرة أخرى، لكن هذه المرة يُبلغ Discourse (بشكل صحيح) الآن بوجود مستخدم واحد في انتظار المراجعة.
عادةً ما تصل رسائل البريد الإلكتروني الخاصة بتنبيهات المستخدمين الذين يحتاجون إلى مراجعة إلى عنوان بريدي الإلكتروني الخاص بالمسؤول بشكل فوري تقريبًا، لذا أنا متأكد إلى حد كبير من أن هذه الرسالة لم تُرسل أبدًا. والآن المشكلة معكوسة تقريبًا!
*تعديل - لقد تلقيت للتو إشعارًا بأن مستخدمين اثنين في انتظار المراجعة (بعد تأخير غير معتاد). ومع ذلك، كان الأيقونة الحمراء الصغيرة بجانب قائمة الهامبرغر تظهر الرقم ‘1’، وعند النقر لعرض قائمة الانتظار، ظهر فقط تسجيل المستخدم الوهمي الواحد الذي أنشأته سابقًا - والذي وافقت عليه، فأشار Discourse إلى عدم وجود مستخدمين آخرين للمراجعة.
بعد ذلك، قمت بتشغيل الاستعلام مرة أخرى - وكان العدد صفرًا.
عذراً، أدركت أن جملة WHERE خاطئة. يجب أن تكون r.type = 'ReviewableUser' بدلاً من User.
هل يمكنك تشغيل هذا بدلاً من ذلك؟
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'ReviewableUser' AND r.status = 1 AND users.approved = FALSE
هل يمكنك التحقق مما إذا كان موقعك يحتوي على أي مستخدمين غير معتمدين بدون كائن قابل للمراجعة مرتبط بهم؟ لقد حاولت إعادة إنتاج هذا الخطأ حتى الآن دون جدوى.
إليك استعلامًا للقيام بذلك:
SELECT COUNT(*)
FROM users u
LEFT JOIN reviewables r ON r.target_id = u.id AND r.type = 'ReviewableUser'
WHERE approved = false AND r.id IS NULL
أيضًا، جرب:
SELECT COUNT(*) FROM users WHERE approved = false AND active = true
غير متأكد مما إذا كان هذا ذا صلة، لكن هناك العديد من المنشورات التي تم استيرادها من مجموعة ياهو منتهية الصلاحية كانت السلف للمنتدى الحالي — تم دمجها لأسباب تتعلق بالاستمرارية وقابلية البحث. غالبًا ما لا يكون لمُنشئي تلك المنشورات القديمة (التي تعود إلى أوائل العقد الأول من القرن الحادي والعشرين) حسابات على المنتدى الحالي.
كان هذا مثيرًا للاهتمام جدًا — كيف يمكن لشخص أن يكون لديه حساب غير معتمد لكنه نشط؟ إلا إذا كنت أنا كمسؤول؟ كيف يمكنني تعديل الاستعلام لتحديد هذا المستخدم؟
