أفهم أن كثيرين سيقولون شيئًا مثل «لكن الردود قد تكون مهمة للآخرين أو للأجيال القادمة». لا أستطيع التأكيد على مدى ضآلة أهمية ذلك، ونحن ببساطة لا نهتم إذا حُذفت جميع الردود.
ولا ينبغي أن يُطلب مني القيام بذلك لكل منشور على حدة.
أعتقد أن هذا قد يعمل بشكل جيد كإعداد موقع من نوع enum، مع بقاء السلوك الحالي كإعداد افتراضي. على سبيل المثال، يمكن أن يوفر permanent_topic_deletion_mode السلوك الحالي المتمثل في «تطلب حذف كل منشور بشكل دائم أولاً»، وسلوكًا اختياريًا آخر يتمثل في «حذف الموضوع وجميع منشوراته بشكل دائم»، لا يزال خلف التأكيد المُدخل الموجود مسبقًا. هذا سيحافظ على سياسة الأمان الحالية للمواقع القائمة، مع السماح للمشرفين الذين يريدون صراحةً الحذف الجماعي باختيار هذا الخيار.
تحديث سريع حول التقدم بعد الغوص في كود الحذف الدائم الحالي:
وجدت أن Discourse يمتلك بالفعل سلوك الحذف الجماعي الفعلي المطلوب هنا. عند تدمير أول منشور بشكل دائم، يمكن لـ PostDestroyer بالفعل تدمير المنشورات المتبقية في الموضوع بشكل دائم بشكل متكرر. القيد الرئيسي يكمن في فحوصات الصلاحيات/السياسات التي تتطلب حاليًا حذف المنشورات الأخرى بشكل دائم أولاً.
لذلك، ابتعدت عن التعداد الشامل للموقع الذي اقترحته أعلاه، وأصبحت لديّ نسخة عمل تعمل باستخدام نموذج اختيار أكثر حذرًا:
يبقى الإعداد الموجود can_permanently_delete كمفتاح رئيسي
هناك بوابة إضافية على مستوى المشغلين، مخفية ومعطلة افتراضيًا
عند تمكين كلاهما، يمكن لكل مدير أن يختار المشاركة بشكل فردي تحت الإعدادات → الواجهة
اختيار أحد المدراء للمشاركة لا يغيّر السلوك لأي مدير آخر
تعطيل البوابة المخفية يعيد السلوك الحالي على الفور على مستوى الموقع
تبقى تأكيدات الحذف الدائم الحالية ووسائل الحماية الأخرى سارية
يُسمّى التفضيل حاليًا:
السماح بحذف الموضوع الدائم بحذف جميع المنشورات
مع الشرح:
عند حذف موضوع بشكل دائم، احذف أيضًا جميع المنشورات المتبقية بشكل دائم بدلاً من طلب حذفها بشكل دائم بشكل فردي.
أضفت اختبارات سياسة/أمان للخلفية، وتغطية للتحكم تؤكد أن الموضوع وجميع المنشورات المتبقية تُزال فعليًا بشكل دائم، وتغطية المخصّص/واجهة برمجة التطبيقات، واختبارات قبول للواجهة الأمامية لظهور التفضيل وحفظه. وهي ناجحة.
أنا أنظر أيضًا إلى تسجيل التغييرات على هذا الاختيار الفردي لكل مدير في سجلات إجراءات الموظفين، لأن تمكين وضع حذف أكثر تدميرًا يبدو جديرًا بأن يكون حدث تدقيق موقوتًا.
سأقوم بنشر طلب الجيت هاب (GitHub PR) بعد انتهائي من ذلك والمراجعة النهائية.
تحديث أخير: تم الآن رفع التنفيذ على شكل طلب سحب (PR) جاهز للمراجعة:
التصميم النهائي هو نهج الاختيار الفردي لكل مشرف كما هو موضح أعلاه، وليس قائمة التعداد على مستوى الموقع التي اقترحتها في الأصل.
تمت إضافة بعض التفاصيل المتعلقة بتجربة المستخدم خلال المرور النهائي:
يتم عرض تفضيل كل مشرف تحت التفضيلات → الواجهة عندما تسمح بوابات مستوى الموقع بذلك
عندما يحذف مشرف اختار المشاركة بشكل دائم المنشور/الموضوع الأول، فإن تأكيد عدم القابلية للعكس يذكر الآن صراحةً أنه سيحذف الموضوع وجميع الردود بشكل دائم
عندما لا يكون المشرف قد اختار المشاركة، تبقى السلالة والكلمات الحالية دون تغيير
لا يزال يتم فرض فترة التهدئة الحالية للحذف الدائم لنفس المشرف
يتم تسجيل تغييرات التفضيلات في سجلات إجراءات الموظفين
كما قمت باختبار المسار الكامل للمشاركين يدويًا على موضوع قابل للتخلص منه يحتوي على ردّين، وتحققت لاحقًا من أن الموضوع وجميع منشوراته قد حُذفت من قاعدة البيانات.
اجتازت فحوصات الاختبار/التحليل الرئيسية على GitHub؛ والطلب الآن بانتظار المراجعة، مع بقاء الفحص الأمني في قائمة الانتظار وقت كتابة هذا النص.
