أود استخدام ويبهوك لإزالة المرسِبين من قاعدة بياناتنا المركزية عند حذفهم من قائمة المراجعة، لكن لا يتم تشغيل أي حدث عند إعداد ويبهوكي بهذه الطريقة. هل من المفترض أن يحدث ذلك، أم أنني أساءت فهم جزء «… وعند تحديث حالته»؟
إعجاب واحد (1)
هل يتم تفعيل “ويب هوك حذف المستخدم”؟
3 إعجابات
نعم. للأسف، لا يتم تمرير عملية الحذف، وأود أن أتحقق تحديدًا فقط عندما يتم حذف مستخدم وحظر عنوان IP الخاص به.
إعجاب واحد (1)
أود طلب إمكانية إخفاء الصور تلقائيًا بشكل افتراضي، وتحديدًا للمشاركات المبلغ عنها من قبل مستخدمين بمستوى TL0. وفي حين أن هناك حاجة لرؤية الصور غير اللائقة واتخاذ الإجراء وفقًا لمعايير كل مجتمع، فإن إخفاء الصور سيكون مفيدًا لأولئك الذين يعملون في مكاتب أو من المنزل مع وجود أطفال حولهم (كما هو حالتي غالبًا).
6 إعجابات
لا يزال واجهة برمجة التطبيقات الخاصة بـ “تجاوز” الحاجة إلى تقييم طابور المراجعة غير كافٍ على مدار فترة زمنية، حيث يتم إعادة حساب التقييم بشكل دوري. إذا لم تتم معالجة الطابور في لحظة إنشاء العنصر القابل للمراجعة، فقد يختفي العنصر “المُجبر” من القوائم المصفاة بعناية قبل أن يتمكن المشرفون من مراجعة هذه العناصر.
ربما ينبغي أن نضيف حقلًا منطقيًا (boolean) يُسمى “force-review” إلى العنصر القابل للمراجعة، ويتم دمجه في استعلام التقييم هنا.
5 إعجابات
تُضباب صور مستخدمين TL0 بشكل افتراضي. ويمكن تعطيل هذه الميزة عبر إعداد blur_tl0_flagged_posts_media.
تم تنفيذ ذلك أيضًا. فعند تعيين علم force_review إلى true، ستظهر عناصر المراجعة المعلقة في الطابور حتى لو لم تحقق الحد الأدنى لعتبة النقاط المطلوبة للظهور.
8 إعجابات
@Roman - آسف لم أعد إليك بخصوص هذا بعد. إذا كان لا يزال من الممكن أن يكون مفيدًا، فقد حصلت على السجلات واستخرجت بعض السجلات (تم تنظيفها من المعلومات التعريفية). يتم التشغيل حاليًا على الإصدار 2.6.0beta3. يبدو أن جميع أخطاء “integer out of range” تتعلق بنوع واحد من السجلات.
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
إعجاب واحد (1)
قد يكون من الجيد أيضًا وجود طريقة لعرض قائمة بالعناصر القابلة للمراجعة التي تم مراجعتها، مع تصفيتها حسب المشرف الذي تعامل مع الأعلام. يبدو أن استخدام مرشح “المُعيَّن لـ” عند البحث في الأعلام التي تم التعامل معها في الماضي مشابه جدًا من حيث الدلالة لشخص يبحث عن مرشح “تم التعامل معه بواسطة”، إلا أنهما مختلفان.
هل يجب أن يستفسر مرشح “المُعيَّن لـ” مع الأعلام/العناصر القابلة للمراجعة المحلولة عن الشخص الذي تعامل مع الأعلام، أم يمكن أن يكون هذا مرشحًا منفصلًا؟
4 إعجابات
أعتقد أن هذه فكرة رائعة @Roman - هل يمكنك إضافتها إلى قائمتك؟
5 إعجابات
أنا أستخدم الويب هوك وواجهة برمجة التطبيقات لإضافة مواضيع جديدة إلى قائمة المراجعة، حتى يتمكن المشرفون من التحقق من امتثال الموضوع الجديد. حاليًا، أضع علمًا على المنشور الأول في الموضوع الجديد باستخدام واجهة برمجة التطبيقات. هذا يعمل، لكنه يبدو كشيء سيء عند عرض سجل إدارة المستخدم. هل هناك طريقة أخرى لا تجعل المستخدم يبدو سيئًا؟
إعجاب واحد (1)
هل هناك سبب يمنعك من استخدام اعتماد المواضيع الجديدة ما لم يكن مستوى الثقة؟ هذه الميزة مدمجة في Discourse.
إعجابَين (2)
أتفق على أن ذلك سيعمل في العديد من حالات الاستخدام. نحن نحتاج إلى وسوم من مجموعات وسوم متعددة، وهو ما لا يدعمه Discourse. نرغب في السماح بنشر الموضوع الجديد دون الحاجة إلى موافقة مسبقة، مع التأكد من صحة الوسوم حسبما يتاح الوقت.
أعتقد أن ما أقترحه هو طريقة لإضافة عناصر عشوائية إلى قائمة المراجعة. حاليًا، هناك ثلاثة أنواع مدعومة: منشور تم الإبلاغ عنه، منشور في قائمة الانتظار، ومستخدم. نحن نستخدم منشور الإبلاغ لأنّه الأقرب إلى ما نريده، لكن سيكون من الجيد إضافة عنصر “مراجعة الوسوم” إلى قائمة المراجعة، حتى لو أمكننا ذلك فقط عبر واجهة برمجة التطبيقات (API).
إعجاب واحد (1)
لا توجد طريقة سهلة لتحقيق ما تريده.
أفضل طريقة للقيام بذلك هي إنشاء إضافة تضيف نوعًا جديدًا قابلًا للمراجعة، ثم نقطة نهاية (endpoint) ما لإنشائها.
إعجاب واحد (1)
هل توجد طريقة لتعطيل هذه النافذة المنبثقة؟ نحن نرفض المزعجين بشكل شبه كامل، وهذا يضيف نقرة واحدة فقط إلى سير عملنا:
3 إعجابات
لقد نشرت عن نفس المشكلة هنا: Account rejection email - #11 by simon.
3 إعجابات
إعجابَين (2)
هل توجد طريقة لإضافة مستخدم قابل للمراجعة إلى قائمة المراجعة عبر واجهة برمجة التطبيقات (API)؟ أم أن هذا متاح فقط للكود الذي ينشئ مستخدمًا جديدًا؟
حالة الاستخدام لدي هي أنني أريد من المشرفين مراجعة أي تحديثات للمستخدمين للتأكد من امتثالها للسياسات. لذا لدي Webhook لتحديثات المستخدم (user_updated)، وأريد إضافة المستخدم المُحدَّث إلى قائمة المراجعة.
أستطيع عكس هندسة كيفية وضع علامة على منشور (/post_actions…) لأنني أستطيع وضع علامة يدويًا على منشور ومراقبة حركة مرور الشبكة، لكنني لا أعرف كيفية فعل الشيء نفسه مع مستخدم. أتخيل أنه شيء مثل /user_actions…
إعجاب واحد (1)
لا توجد طريقة للقيام بذلك عبر واجهة برمجة التطبيقات (API) في الوقت الحالي. أعتقد أنك ستحتاج إلى إضافة مكون إضافي يعترض تحديثًا للمستخدم وينشئ عنصرًا قابلًا للمراجعة.
إعجابَين (2)
تم تقسيم منشورين إلى موضوع جديد: الاستجابة لموافقات المنشورات
مرحباً، هذا نقد بنّاء لقسم مراجعة المحتوى.
أعلم أنه تم إجراء بعض التحسينات على أزرار “رفض / موافقة” لجعلها أقل غموضًا (“هل أوافق على المنشور أم أوافق على العلامة؟”). ولكن لا يزال هناك معنى مزدوج لهذه الحالات، مما يجعل مراجعة قائمة العناصر التي تم التعامل معها بالفعل مربكة للغاية بالنسبة لي لأن عامل تصفية الحالة والحالة في أعلى اليمين لا يعنيان شيئًا حقًا. إليك بعض الأمثلة:
تمت الموافقة على منشور تم وضع علامة عليه بسبب الكتابة بسرعة كبيرة – تمت الموافقة على المنشور – الحالة: تمت الموافقة
تمت الموافقة على علامة على منشور غير لائق – تم رفض المنشور – الحالة: تمت الموافقة
تم رفض مستخدم بسبب بريد عشوائي في الملف الشخصي – تم تعليق المستخدم – الحالة: مرفوض
تم رفض علامة على منشور – يبقى المنشور – الحالة: مرفوض
لذلك يبدو أنه يحتاج إلى التمييز بين الحالات التالية، ويمكن أن يكون لبعض العناصر كلتاهما:
- تمت الموافقة على المستخدم/المنشور
- تم رفض المستخدم/المنشور
--- - تمت الموافقة على الإشراف
- تم رفض الإشراف
اقتراح آخر للتحسين في حالة مرسلي البريد العشوائي في ملفات تعريف المستخدمين، سأقدر خيار حذف الحساب وحظر البريد الإلكتروني ولكن ليس عنوان IP، لأنهم غالبًا ما يستخدمون نطاقات IP مشتركة يمكن للمستخدمين الشرعيين استخدامها أيضًا.
إعجاب واحد (1)