يجب أن يكون المستخدمون الإداريون قادرين على إدارة المستخدمين الآخرين عبر وحدة التحكم
لتوفير إدارة المستخدم عبر واجهة الويب (حاليًا ممكن فقط عبر CLI)
لا شيء من هذا القبيل.
منطقة المسؤول داخل وحدة التحكم ، حيث يمكن للمسؤولين تكوين مستخدمي النشر. هذا يتضمن:
وحدة التحكم
في القائمة المنسدلة للمستخدم (الزاوية اليمنى العلوية) ، يمكننا إضافة قسم "إعدادات المسؤول" ، والذي يظهر فقط عندما يكون لدى المستخدم علامة المسؤول. يمكن أن تكون إدارة المستخدم طريقة عرض بسيطة ، تسرد جميع المستخدمين (مع البحث) وجميع المستخدمين غير المعتمدين وزرًا لدعوة المستخدمين عبر البريد الإلكتروني.
سأقوم ببعض الإطارات السلكية السريعة لـ POC.
نعم.
أنا أبحث في هذا الآن وأتساءل عما إذا كان يجب أن يكون هذا جزءًا من تطبيق الحساب الجديد بدلاً من (# 1422) نظرًا لأن إدارة المستخدمين تبدو لي وكأنها مصدر قلق كبير.
أعتقد أنه قد يكون من المفيد تجميع هذه المخاوف الإدارية الشاملة في تطبيق الحساب لتشكيله أيضًا كأداة تكوين مكدس / نشر مع الحفاظ على نطاق وحدة التحكم للإدارة المتعلقة بالشبكة. يمكننا جعل هذا متاحًا في وحدة التحكم ثم عن طريق إضافة روابط إلى تطبيق الحساب (ويفضل أن يكون ذلك في القائمة المنسدلة للمستخدم).
أفكارjohanstokkinghtdvisser؟
رأيي ذو شقين. الأول هو أنه ليس لدينا وقت لانتظار # 1422 للحصول على إدارة أساسية للمستخدم ، والثاني هو أنني أعتقد أن ما سيكون عليه تطبيق الحساب الجديد بمجرد تحديده ، يتعلق في الغالب بالمستخدم نفسه ، وليس عن المستخدمين الآخرين.
أتفق مع تعليق johanstokking . سيكون تطبيق الحساب مخصصًا لإدارة "حساب المستخدم الخاص بك" ، وستكون وحدة التحكم لإدارة الشبكة ، وعندما تكون مسؤولاً يتضمن مستخدمي شبكتك.
دفع هذا إلى مستوى مرتفع لتجنب تجربة مستخدم CLI فقط في مرحلة الإعداد الأولية لعمليات النشر.
أرغب في إضافة جدول صغير للمستخدمين غير المعتمدين إلى عرض إدارة المستخدم في وحدة التحكم. وإلا ، فسيتعين على المستخدم إدخال معرف المستخدم يدويًا.
هل يستحق تمديد محاولات RPCs لهذا الغرض؟ الآن لا يمكننا تصفية قائمة RPC. وبالمثل ، من شأنه تحسين تجربة المستخدم كثيرًا إذا كان المرء قادرًا على البحث في قائمة المستخدمين.
لدينا محاولات RPCs للبحث عن ذلك. لقد خططنا بالفعل لإضافة مرشح state
إلى هؤلاء.