If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?
End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue
This is an interesting use case and I’d like to help you get it working.
Actions for reviewable types are returned from the build_actions method.
What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.
That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.
روبن،
أنا أجهز حاليًا طلب دمج (PR) لـ إضافة OAuth الخاصة بـ Discord بهدف تخزين معلومات أكثر عن مستخدمي Discord في Discourse. أحاول استخدام نموذج ReviewableUser الخاص بك للحفاظ على الوظائف التي تنفذ الموافقة الآلية.
نظرًا لأن التنفيذ الحالي يدخل في مراجعة للمستخدمين الجدد بشكل غير متزامن، أحتاج إلى التحقق مما إذا تم إنشاء مثل هذه المراجعة وحذفها.
للأسف، أواجه خطأً غريبًا في Ruby وتساءلت عما إذا كنت قد صادفته من قبل.
الكود هو:
def after_create_account(user, auth)
super
data = auth[:extra_data]
if !user.approved && data[:auto_approve]
user.approved = true
user.approved_by_id = Discourse.system_user.id
if reviewable_user = ReviewableUser.find_by(target: user)
reviewable_user.set_approved_fields!(user, Discourse.system_user)
end
end
end
بمجرد استدعاء ReviewUser.find_by، أحصل على استثناء:
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
رغم أنني اعتقدت أنني أحرز تقدمًا جيدًا في Ruby، إلا أنني غير واضح بشأن سبب حدوث هذا!
هل هي مشكلة في المسار؟ لقد جربت العديد من عمليات الـ requires، لكن ذلك أدى إلى تفاقم المشكلة.
إنها تشبه أنماطًا مشابهة في مكان آخر في الكود الأساسي. أي أفكار من قبلكم تُقدّر كثيرًا!
المستودع هنا إذا احتجت إليه: discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
هذا الخطأ المستمر غير مفيد جدًا، أليس كذلك! أعتقد أنه يتعلق بمحركات Rails ومساحات الأسماء. يمكنك تجربة أمر سريع وهو استخدام ::ReviewableUser مع نقطتين عموديتين قبله. هذا يخبر النظام باستخدام مساحة الأسماء الجذرية وليس داخل المحرك.
يبدو هذا الكود أيضًا قديمًا بعض الشيء بالنسبة لواجهة برمجة التطبيقات الخاصة بـ Reviewable. يجب أن يكون شيئًا مثل هذا:
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
تم حل الخطأ. أفترض أنه بسبب عدم قدرته على العثور على Class من قبل، كان يعامله كـ Constant؟ على أي حال، تم حل المشكلة، رائع، شكرًا جزيلاً! لقد تخلصت من المشكلة!
إذن، السبب في أنني استخدمت هذا:
user.approved = true
user.approved_by_id = Discourse.system_user.id
قبل:
reviewable.perform(:approve, Discourse.system_user)
هو أن الإضافة إلى قائمة المراجعة غير متزامنة. في المهمة، يتم إنشاء المراجعة فقط إذا كان approve خاطئًا من (discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub):
if user = User.find_by(id: args[:user_id])
return if user.approved?
@reviewable = ReviewableUser.needs_review!(
target: user,
created_by: Discourse.system_user,
reviewable_by_moderator: true,
payload: {
username: user.username,
name: user.name,
email: user.email
}
)
هل هناك خطر من أن المهمة قد تُنفَّذ بعد أن تختبر وجود إدخال المراجعة؟
النتيجة هي أن إدخال المراجعة لا يبدو موجودًا، لكن المهمة في انتظار التنفيذ. ثم تُنفَّذ المهمة وتُنشئ إدخال المراجعة، وقد فوّت الفرصة لحذفه لأن كودك لاختبار ذلك قد نُفِّذ بالفعل.
هل هذه حالة سباق محتملة؟
اجعل approved true قبل التحقق من وجود إدخال المراجعة، وستكون قد حَللت المشكلة (لأنه لن يتم إنشاء مراجعة بعد ذلك نظرًا لأنها شرط مسبق).
لقد واجهت هذه المشكلة أثناء اختبار كودي - عملت على بيئة التطوير، ثم فشلت على الإنتاج لأن الأمور نُفِّذت بترتيب مختلف.
ملاحظة: أقدر أنك لم تكتب هذا لدعم حالة الاستخدام هذه، لكن أعتقد أنه من المهم السماح للإضافات بالموافقة التلقائية على المستخدمين الجدد في ظروف خاصة (مثل إضافة Discord التي تفعل ذلك إذا كان المستخدم عضوًا في نقابة موثوقة).
في الواقع، يتم إنشاء السجل القابل للمراجعة بشكل غير متزامن، وهو ما يشكل مشكلة في هذه الحالة، حيث أن تسجيل الدخول سينشئ المستخدم وقد لا يكون سجل الموافقة موجودًا بعد.
الحل الأفضل هو عدم إنشاء السجل القابل للمراجعة في هذه الحالة، غير أن ذلك سيتطلب تعديلات في النواة (core) ليعمل بشكل صحيح. يمكن أن يعمل الأمر على النحو التالي:
skip_approval: true.شكرًا لك يا روبن، نعم.
في الوقت الحالي، اعتمدت على حلي البديل مع وعي بأن الأمر سيحتاج إلى معالجة قبل إزالة الوصول المباشر إلى واجهة برمجة التطبيقات (API).
هل يوجد لدى الفريق أي رغبة في إعطاء الأولوية لذلك قبل إزالة حق الكتابة المباشر للمستخدم.approve؟
أعتقد أن هذا التغيير سيكسر ميزة الموافقة التلقائية الموثوقة الحالية في إضافة تسجيل الدخول عبر ديسكورد (Auth Discord Login plugin) (حتى بدون طلب السحب الذي قدمته للتو إلى هذه الإضافة). @featheredtoast
سأكون سعيدًا بتحديث طلب السحب الخاص بي لدعم هذا التغيير في حال تم تنفيذه.
لا أرى أننا سنقوم بإزالة هذا في أي وقت قريب. لا أريد الاعتماد عليه إلى الأبد، لكنه يجب أن يكون جيدًا لفترة من الوقت.
الطابور رائع، ووظيفة “التجميع حسب الموضوع” مفيدة أيضًا.
ومع ذلك، حسب فهمي، لا توجد طريقة لاختيار المنشورات ومعالجتها دفعة واحدة. بل يجب معالجة كل منشور على حدة.
سيكون الاختيار والمعالجة الدفعية توفيرًا حقيقيًا للوقت!
أعتقد أن هذا سيكون تحسينًا رائعًا. وبالمقارنة العادلة، فإن قائمة الأعلام لم تكن تحتوي أبدًا على عمليات مجمعة، لذا لا يمكن اعتبار هذا تراجعًا.
كما أن بعض العمليات مثل “تعليق” تبدو غريبة قليلاً عند تطبيقها على عدة صفوف. سيكون من الضروري حصرها في العمليات الأساسية لكي يكون لها أي معنى.
وجدت مشكلة صغيرة: نشر شخص ما في تصنيف يتطلب موافقة، لذا ظهر في قائمة المراجعة. لقد نشر في التصنيف الخاطئ، لذا حاولت تغييره من قائمة المراجعة. لم تكن هناك مشكلة باستثناء أن التصنيف الذي أحاول نقله إليه يتطلب وسمًا واحدًا، لكن هذا الوسم مقيد بالتصنيف الجديد، بينما لا يزال المنشور في قائمة المراجعة يعتقد أنه في التصنيف الأصلي الذي لا يسمح بذلك الوسم، فأنا عالق. من السهل الموافقة على المنشور وتغييره لاحقًا، لكن يبدو أن هذا شيء يجب إصلاحه.
أعلم أن هذا من المفترض أن يتم إصلاحه، لكن الروابط لا تزال لا تُضاف إلى قائمة الفحص. ربما لا يهم ذلك حقًا، لأن الإجراء المخصص للروابط المفحوصة يقول
فقط للتأكد من أنك قمت بالترقية إلى الإصدار الصحيح؟ يجب فحصها إذا لم تكن قادرة على Onebox أو داخلية.
نعم، أنا على الإصدار v2.4.0.beta2 +66. سأقوم بنسخ المنشور في المرة القادمة التي يحدث فيها ذلك.
نعم، بعد النقر على “حذف المستخدم” في قائمة المراجعة، تمت إضافة عنوان البريد الإلكتروني وعنوان IP إلى القوائم الخاضعة للمراقبة، لكن لم تتم إضافة أي عناوين URL. كان المنشور كالتالي:
هل ترغب في [خدمة الكتابة الأكاديمية](https://myassignmenthelp.com/uk/academic-writing-service.html) عبر الإنترنت لدى مزود خدمة الكتابة الأكاديمية رقم 1 عالميًا Myassignmenthelp.com. نقدم خدمة كتابة أكاديمية احترافية تشكّل مجموعة واسعة للطلاب بأفضل الأسعار.
حسب ما أتذكر، لم تتم إضافة عناوين URL إلى القائمة المفلترة تلقائيًا أبدًا؟ حسنًا، أظن أنها تُضاف، لقد تفحصت نسختي وهناك العديد من عناوين URL هناك ؛)
آه نعم، تذكرت. إنها لا تفعل شيئًا فعليًا، إنها فقط لأغراض إعلامية.
يمكنك إضافة أسماء النطاقات هذه إلى الكلمات المراقبة بحيث لا يمكن إدخالها، لكن سيتعين عليك القيام بذلك بنفسك.
لهذا السبب سيكون من الجيد إضافتها إلى قائمة المراقبة - حتى لو لم يتم اتخاذ أي إجراء تلقائي على الروابط، فإن ذلك سيسمح لنا برؤية نوع الرسائل المزعجة التي يتم نشرها. ضع في اعتبارك أن المشرفين قد يستخدمون قائمة المراجعة، لكن لا يمكنهم (أعتقد) إضافة كلمات مراقَبة.
بعض الملاحظات البسيطة حول تجربة المستخدم: سيكون رائعًا لو تذكرت قائمة المراجعة إعداداتي. نظرًا لأننا نعمل مع فريق من المشرفين، فأنا مهتم شخصيًا برؤية الأعلام الجديدة وأقوم بالفرز حسب “تاريخ الإنشاء”، لكن هذا الإعداد لا يثبت.
هذه ليست فكرة سيئة. لحسن الحظ، يوجد حاليًا حل بديل: تُحفظ فلاتر البحث في سلسلة الاستعلام (عنوان URL). إذا قمت بإضافة إشارة مرجعية لفلتر معين، يمكنك دائمًا العودة إليه.