أتفق معك فيما قلته، لكنني أشك في أن هذه الدراما “القليلة” يمكن أن تكون جيدة لأن الناس يفهمون ما يعنيه إدارة و/أو حماية البيانات الشخصية أو بيانات الطرف الثالث (هناك مسؤوليات اجتماعية متضمنة).
شكرًا للاستماع، يمكنني التأكيد على أننا اخترنا Discourse بشكل جيد جدًا لمشروعنا. وبالطبع، أقدر تمامًا طلب السحب الخاص بك 
أعتقد أننا سنحتاج إلى تقييد الوصول إلى إعداد allow_allow_impersonation هذا، فهو قوي للغاية! ربما إعداد آخر؟ 
المكون الإضافي الوحيد الذي يحكمهم جميعًا!
من المؤسف أن Procourse Installer لم يحصل على دعم أفضل.
لا لا، يجب أن يكون في وحدة التحكم أو في الكود المصدري على الأقل، من المغري جدًا السماح بهذا الإعداد واستخدامه. انتظر، لكن يمكنني الوصول إلى وحدة التحكم أيضًا. 
للتوضيح، لن يتمكن جميع المسؤولين من الوصول إلى وحدة التحكم.
أفترض أن الفكرة مشابهة جدًا لعدم السماح للمسؤولين بشكل عام بالقدرة على انتحال شخصية النظام أو Discobot.
بالأمس فقط كنت بحاجة إلى انتحال شخصية مستخدم للعثور على خطأ أثر على هذا المستخدم فقط (الذي كان لديه منطقة زمنية غير صالحة في الملف الشخصي).
إذا كنت لا تثق في المسؤولين لديك، فإن انتحال شخصية المستخدمين هو أقل ما يدعو للقلق.
لكن كما ذكرنا، فإن وجود خيار لتقييد وصول المسؤولين ليس أمرًا سيئًا. لكن @sam قدم حلاً بسيطًا لراحة البال لمن يرغبون في ذلك. والذي لا يؤثر على أولئك الذين يحبونه كما هو.
كانت المشكلة الأكبر في هذه المناقشة هي الرؤية النفقية بدلاً من رؤية الإيجابيات والسلبيات التي تتجه نحو التوصل إلى حل وسط يناسب الجميع. أعتقد أن طلب Sam التنفيذي يناسب طلب صاحب الطلب بتطبيق طبقة إذا كان مفضلاً.
من فضلك هل يمكن للموظفين إغلاق هذا الموضوع؟
لقد أصبح الأمر غير منطقي بعد حل أساسي بسيط وواضح للغاية دون أي سلبيات سوى الهراء هناك.
Super-admin > admin > mods > lvl 4 صفقة جيدة جدًا للمجتمعات، وليس للمطورين الفرديين.
والمطورون الفرديون ليسوا ما كنا نتحدث عنه
