The delete user action is found under different top level buttons depending on the type of flag. It would be nice if the Delete button always had a delete user sub action.
And btw, URLs are added to the screened list if you delete from a manually flagged review, just not from user posted too fast reviews.
I just had some odd things happen relating to flagging of a post in a personal message. Two people are in the message (myself and a new moderator I am in the process of onboarding). We were testing out flagging, and she flagged one of her own posts. Both of us received the notification that our message was flagged as spam and that we should edit and fix it, and neither of us could directly reverse the flagging action directly in the post. It also did not show up in the review queue.
While the post was hidden, I selected the post admin wrench but was unable to use it because it was somehow behind the post content. See screenshot.
Only when I edited the post did it get unhidden.
So… several issues:
I’ve been loving the improvements here - I’ve finally had a chance to collect my thoughts and accumulate a bit of feedback about this:
ميزة أخرى يجب أن نضيفها: اجعل العناصر التي تم إعادة علمها لا تظهر مرة أخرى في قائمة المراجعة إلا إذا تم تعديل محتوى المنشور أو تغييره بطريقة ما. يجب أن يتجاهل هذا تلقائيًا عناصر العلم الجديدة، ولا يمكنه إخطار المنشور أو إخفاؤه.
الفكرة هنا هي أن أحد المشرفين في مكان ما قد رأى العلم بالفعل وتعامل معه، وأي عناصر جديدة (من نفس النوع) ستُعالج بنفس الطريقة.
تحذير واحد بخصوص ما سبق: يجب أن نتجاهل على الأرجح أي علامات جديدة بدلاً من حل العناصر القابلة للمراجعة تلقائيًا بنفس الطريقة التي تم بها التعامل مع العلم فعليًا (مثل الموافقة)، لأن ذلك قد يؤدي إلى نتيجة غير مقصودة تتمثل في منح مستخدمي العلم الذين يسببون إزعاجًا القدرة على رفع درجات علمهم من خلال وضع علامات على أشياء وافق عليها المشرفون مع الإبقاء عليها.
نقطة ممتازة. ولإضافة إلى ذلك، فإنني أوافق بانتظام على منشورات يتم بعد ذلك تصنيفها على أنها رسائل غير مرغوب فيها بواسطة Akismet. ومن المرجح ألا يحدث ذلك أيضًا.
نعم بالتأكيد - يجب أن تظل للإضافات القدرة على تجاوز الاقتراح المذكور أعلاه إذا لزم الأمر، لكنني أتفق على أن أكismet لا ينبغي أن تفعل ذلك في هذه الحالة. قد تكون هذه مشكلة متعلقة بإضافة أكismet، لكنها نقطة ممتازة.
هذه مشكلة في الإضافة، وسأقوم بدفع إصلاح لها.
لقد بدأت بالفعل في البحث في هذا الأمر. أنا أتفق على أننا بحاجة إلى تجاهل الأعلام الجديدة بدلاً من حلها تلقائيًا. كنت أفكر في عرض رسالة خطأ عندما يحاول شخص ما إعادة تصنيف منشور تمت مراجعته.
وكنت أفكر أيضًا أنه يجب على المستخدمين الانتظار لمدة 24 ساعة تقريبًا قبل أن يتمكنوا من إعادة تصنيف منشور لنفس السبب.
نظرًا لأن جميع البنود المعلقة الأحدث موجودة في قائمة “عرض الكل”، يجب أن يعيد تبويب “المراجعة” توجيهنا إلى تلك القائمة بدلاً من قائمة “المجمّعة حسب الموضوع”.
هل قمت بتعيين المواضيع الافتراضية القابلة للمراجعة؟ هذا يتسبب في افتراضها للمواضيع بدلاً من جميع العناصر، وهو ما يجب أن يكون الافتراضي.
لقد دمجنا هذه الميزة للتو:
وفقًا لـ https://meta.discourse.org/t/discourse-2-4-0-beta11-release-notes/141548:
يُوجَّه المستخدمون المشبوهون إلى قائمة المراجعة
يُوجَّه المستخدمون المشبوهون - أولئك الذين شاهدوا أقل من منشور واحد ومن أقل من موضوع واحد ولكنهم قاموا بتخصيص سيرتهم الذاتية - إلى قائمة المراجعة. يتمتع هؤلاء المستخدمون باحتمالية عالية بأن يكونوا من المرسلي البريد المزعج، حيث أن معظم المستخدمين يتصفحون الموقع قبل أن يتفرغوا لملء سيرتهم الذاتية.
هذا لا يحدث في حالتنا؛ تظهر مستخدمون مشبوهون جدد في /admin/users/list/suspect كما هو معتاد، لكن لا تظهر في قائمة المراجعة. هل يعتمد ذلك على بعض الإعدادات؟
نعم، تعتمد الميزة على إعداد “اعتماد المستخدمين المشتبه بهم” (معطل افتراضيًا).
عظيم، إنه يعمل الآن (ربما يجب إضافة هذا النوع من المعلومات إلى ملاحظات الإصدار).
لكن لدي طلب صغير سيساعدنا في تسريع عملية المراجعة: هل يمكنك ربط حقل الموقع الإلكتروني؟ حاليًا، علينا نسخه ولصقه، مما يبطئنا بشكل كبير.
يبدو أن هذا حقل مستخدم أضفته. للأسف، لا نملك طريقة لمعرفة ما إذا كانت هذه روابط أم لا.
حقل ‘الموقع الإلكتروني’؟ هذا ليس حقلًا مخصصًا (مثلما هو هنا على Meta). الحقلان الآخران مخصصان، لكنني لا أحتاج إلى أن يكونا مرتبطين مباشرةً.
من المنطقي أن يكون حقل موقع الويب القياسي نشطًا. سيكون رائعًا لو تضمن تتبع عدد النقرات.
أعتقد أنه يجب أن تتمكن من جعل حقولك المخصصة قابلة للنقر باستخدام مكون السمة.
نقر مزدوج، Control-C، Control-T، Control-V، Enter
خطأي! لقد تحققت من ذلك هنا على ميتا، ولم يكن لدى المستخدم الذي نظرت إليه موقع ويب. بالإضافة إلى ذلك، أُلقيتُ في حيرة بسبب حقول المستخدم الأخرى الموجودة مباشرةً في الأسفل. هذا الرابط سيربط الموقع لتسهيل المراجعة:
بعد التفكير في الأمر أكثر، يبدو أن نافذة تبريد مدتها 24 ساعة مناسبة للمواقع الأصغر، لكنني قلق من أن المستخدمين قد لا يزالون قادرين على إغراق المشرفين في موقع أكبر.
ما رأيك في جعل نافذة عدم إمكانية وضع علامة متغيرة (أو قابلة للتعديل على الأقل عبر إضافة خارجية)؟ أي إجراء يمكننا اتخاذه لتخفيف العبء المحتمل على المشرفين سأعتبره فوزًا.
مسألة أخرى غير مرتبطة: قد يُنظر إلى المستخدمين ذوي الثقة العالية على أنهم يمتلكون صلاحيات “المشرف” مع القدرة على إخفاء منشور بعلامة واحدة. قد لا يزال من المرغوب فيه الاحتفاظ بالحد الأدنى السابق لعدد العلامات المطلوبة لإخفاء المنشور كخيار، حتى لا يتمكن عضو واحد في المجتمع من التصرف كرقاص.
نعم، بعد الكثير من التبادل، لستُ حقًا ضد إعادة وضع الحد الأدنى للعدد. أود التأكد من أن عميل @featheredtoast قد جرب التعديلات الأخرى أولاً وهو متأكد من أن هذا سيكون مفيدًا.
@Roman، هل يمكننا جعل نافذة الـ 24 ساعة قابلة للتكوين؟
تم الإنجاز هنا:
يمكن تمكينه أو تعطيله عبر الإعداد high_trust_flaggers_auto_hide_posts.
يمكن تكوينه باستخدام الإعداد cooldown_hours_until_reflag (الافتراضي 24 ساعة).
