يجب أن يؤدي النقر على الظرف للكشف عن بريد إلكتروني وارد إلى العمل للموظفين وللمستخدمين الذين يعرضون منشوراتهم الخاصة. ومع ذلك، كمستخدم غير موظف يحاول عرض منشوره الخاص، يؤدي هذا إلى خطأ في جافاسكريبت. يمكن للمستخدم عرض ملف JSON الأساسي عندما يتم طلب ذلك يدويًا.
إنه يعمل للموظفين.
يمكنني تأكيد أن هذا يحدث أيضًا في موقع الاختبار الخاص بي للمستخدمين غير الموظفين بنفس الخطأ - Uncaught Error: Failed to create an instance of 'controller:raw-email'. Most likely an improperly defined class or an invalid module export.
لقد تم تمييزه لبعض الاهتمام. 
يبدو شرعيًا! شكرًا على طرحه، نظرًا لأن القطع الورقي صغير جدًا، فسأضع عليه علامة pr-welcome. أنا أؤيد الإصلاح البسيط للغاية المتمثل في عدم استدعاء أي شيء هنا، وأنا متردد بشأن الكشف عن معلومات البريد الإلكتروني الكاملة للذات لغير المشرفين.
لعدم استدعاء أي شيء؛ لقد استخدمت ذلك لتصحيح مشاكل البريد الإلكتروني مرات لا تحصى كمسؤول، ولم ألقِ نظرة على رسائلي الخاصة كمشرف أو مستخدم عادي، في أي مكان. 
تم إغلاق طلب السحب هذا (بصمت)، وأظن أن السبب هو أنني بصراحة لا أرى كيفية اختبار دالة من سطر واحد تحتوي فقط على is_staff?.
يرجى إخباري إذا كان سيتم دمج هذا في المستقبل، لأنه إذا لم يكن كذلك، فسيتعين علي إنشاء إضافة لحل مشكلة اللائحة العامة لحماية البيانات هذه…
يمكنني قبول عدم وجود اختبار للجانب العميل إلى حد ما، ولكن يجب أن يكون اختبار جانب واجهة برمجة التطبيقات (API) سهلاً. تقوم بإنشاء كائن منشور، وكائن مستخدم، وتتحقق من أن المستخدم لا يمكنه عرض البريد الإلكتروني الخام عند حذف المنشور في اختبارات الحارس.
سأحاول معرفة سبب إغلاق طلب السحب (PR).
هذا تغيير في السلوك، أنا فضولي لماذا نتجه نحو إزالة الميزة بدلاً من إصلاح الخلل.
نشتبه في أن الإغلاق كان نقرة خاطئة من شخص ما، نعتذر، تم إعادة فتحه.
هذا غريب بالتأكيد لأنني لا أعتقد أنه كان مقصودًا إغلاقه ولم أكن أنا من أغلقه. على الأقل ليس عن قصد وليس على حد علمي. على أي حال، سأتابع طلب السحب قريبًا.
هناك شيء غريب في حالة طلب السحب. خطأ في GitHub ربما؟ 
كان الإغلاق غريبًا جدًا بالفعل، حيث لم يكن هناك مستخدم نشط ولم أتلق إشعارًا.
يسرني سماع أن الأمر لم يكن متعمدًا!
ربما أسأت فهمك هنا إذن…؟
آسف على الانتظار الطويل هنا. تم دمج طلب السحب.
