يبدو أن صلاحية المشرف تخلط بين دور “مدير الخادم” ودور “المشرف الرئيسي”.
سؤالي قائم على حالة الاستخدام لدينا، حيث قام قسم تكنولوجيا المعلومات بإعداد مثيل خادم Discourse الخاص بنا، لكنه لا يتحمل أي مسؤولية أو اهتمام بتشغيل أو تطوير المحتوى داخل Discourse.
هل توجد طريقة لفصل الخيارات التي ينبغي أن يكون “مدير الخادم” مسؤولاً عنها (مثل تكوين SSL) عن المهام التي سيقوم بها “المشرف الرئيسي”، مثل إعداد الفئات؟
لا يحتاج مسؤول تكنولوجيا المعلومات المسؤول عن إعدادات SSL، على سبيل المثال، حتى إلى حساب في Discourse، بل فقط إلى الوصول إلى الخادم. بالإضافة إلى ذلك، يمكن تعيين معظم الإعدادات المتعلقة بتكنولوجيا المعلومات كمتغيرات بيئة في ملف app.yml، مما يجعل الوصول إلى تكنولوجيا المعلومات غير ضروري للجزء الخاص بالويب من Discourse.
بهذه الطريقة، يمكن لمشرفك “الرئيسي” أن يكون مسؤولاً أو مشرفاً في Discourse دون أي مشاكل.
شكرًا لك @Falco.
إذن، هل من الممكن وجود مستويات ضمن صلاحيات المسؤول؟ حيث يمكن للمسؤول من النوع 2 القيام بـ XYZ ولكن ليس بـ JKL؟
لا، لا يوجد نظام أذونات مخصص بدقة.
@Falco، يبدو لي أن هذا أمر غير محبّذ إلى حد ما.
هناك بعض الحقول في قسم Email تثير قلق بعض مديري الخوادم بينما لا يحتاجها المشرف الرئيسي حقًا. على سبيل المثال: حساب البريد الإلكتروني وكلمة المرور، ورقم المنفذ المستخدم لاستقبال الرسائل عبر بروتوكول POP3، وغيرها من التفاصيل.
بالإضافة إلى ذلك، توجد العديد من معاملات Admin الأخرى التي قد تؤثر على حمل الخادم، ويمكنني بسهولة تخيل رغبة مديري الخوادم في التحكم في هذه الإعدادات أيضًا. كمثال بسيط: الحد الأقصى لحجم ملفات الصور والمرفقات. وبعد استعراض جميع خيارات الإدارة، نجد أن هناك الكثير من الإعدادات التي ينبغي أن يتحكم فيها مدير الخادم بدلاً من المشرف الرئيسي.
الخلاصة في أسئلتي هي أن الفريق المسؤول عن الواجهة العامة قد يتعثر بسهولة بسبب الفريق المسؤول عن الخلفية، رغم أن كلاهما لديه مخاوف مشروعة.
هل توجد ربما قالب المشرف الرئيسي يلغي الوصول إلى بعض المعاملات من لوحة الإدارة؟
يمكنك وضع هذه الإعدادات في قسم app.yml الخاص بـ env، ولن تكون مرئية في واجهة المستخدم.
راجع استخدام التخزين الكائني للuploads (نسخ S3) للحصول على أمثلة. يمكن تجاوز وإخفاء جميع إعدادات الموقع بهذه الطريقة.
شكرًا لك @pfaffman.
لقد اطلعت على الرابط الذي يشير إلى التخزين الخارجي، لكنه قد يكون مربكًا بعض الشيء للمستخدم الجديد.
لذا، كما أفهم الأمر، فإن ما تقوله ينقسم إلى جزأين: (1) يمكن تكوين جميع الإعدادات الظاهرة في منطقة الإدارة في ملف app.yml، و(2) أن منطقة الإدارة لن تعرض أي خيارات تم تكوينها في ملف app.yml.
هل هذا صحيح؟
السؤال التالي هو: هل يمكن تصدير إعدادات المسؤول الحالية إلى ملف، ليتم دمجها في ملف app.yml؟
يبدو أنك تفهم. ستحتاج إلى إنشاء قيم المتغيرات البيئية يدويًا.