يبدو أنني أغفلت شيئًا في هذا المنشور: Let's talk Moderation - #2 by simon. الإيقافات السابقة تؤثر بالفعل على ترقيات tl3. من الغريب كيف يتم حساب المتطلبات المدرجة هنا مرتين في عملية الترقية:
أولاً في مهمة ترقية tl3، ثم مرة أخرى من استدعاء review_tl2. تقوم هذه الطريقة بحساب متطلبات tl3 مرة أخرى، مع مراعاة عقوبات إسكات المستخدمين وإيقافهم: discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub.
هذا أمر مهم إلى حد ما، لأن الإيقافات تُستخدم غالبًا كوسيلة لإلغاء الوصول إلى موقع بشكل مؤقت بطريقة غير مقصودة لمعاقبة المستخدمين، على سبيل المثال، يتم إيقاف المستخدمين عند انتهاء صلاحية عضوية مدفوعة على تطبيق خارجي.
تعديل: يبدو أنه إذا تم إيقاف مستخدم، ثم إلغاء إيقافه بواسطة مستخدم ليس هو المستخدم النظامي، فسيتم إزالة عدد العقوبات: discourse/app/models/trust_level3_requirements.rb at main · discourse/discourse · GitHub. هذا يعني أنه إذا تم إيقاف مستخدم عن طريق الخطأ، ثم تم إلغاء إيقافه بواسطة مستخدم بشري، فلن يكون هناك عدد عقوبات. هذا يعني أيضًا أنه في حالة إيقاف المستخدمين “إلى الأبد” كوسيلة لإزالة الوصول إلى الموقع عند انتهاء صلاحية اشتراك خارجي، فلن يكون هناك عدد عقوبات عند إلغاء إيقافهم، طالما أن إلغاء الإيقاف لا يتم بواسطة المستخدم النظامي.
هذا المنطق منطقي، ولكن ربما يمكن جعله صريحًا في مكان ما. من الشائع جدًا إيقاف المستخدمين وإلغاء إيقافهم عبر واجهة برمجة التطبيقات (API). لم أكن أعرف حتى الآن أن الأمر مهم ما إذا كان الإجراء قد تم تنفيذه بواسطة المستخدم النظامي أم لا.
يتم استخدام نفس المنطق لعدد العقوبات الخاصة بإسكات المستخدم.