"الوضع العادي" للمسؤولين والمشرفين (مثل "sudo")

أنا مسؤول و مشارك في مواقع مناقشة Fedora. أود أن أكون قادرًا على فصل هذين الدورين. أعرف أن هناك “لون الموظفين” للمنشورات الرسمية، لكنني أقصد المزيد من جانبي. بدلاً من مفاتيح وأزرار المسؤول في كل مكان عندما أكون مسجلاً الدخول، أود مفتاح تبديل في القائمة لتفعيل وضع المسؤول وإيقافه.

15 إعجابًا
6 إعجابات

لدينا أيضًا

تتيح لك كلتا الإضافتين إخفاء هويتك كموظف. على سبيل المثال، يمكنك إنشاء منشور من حساب يبدو أكثر “رسمية”، ولا يمكن ربطه بك بوضوح كفرد.

ومع ذلك، لا أعتقد أن هذا هو ما تطلبه بالضبط؟ أنت تريد طريقة لجعل Discourse يبدو/يشعر كما هو الحال بالنسبة للمستخدمين العاديين، ثم “الدخول إلى وضع sudo” لجعل جميع الوظائف الإضافية المتاحة للمسؤولين متاحة؟

أعتقد أنه سيكون من الصعب جدًا تنفيذه… ولكنه سيكون رائعًا جدًا! قبل سنوات عديدة (قبل انضمامي إلى الفريق)، قمت بإنشاء هذا المكون لمنتدى خاص بي. لديه نفس الفكرة (جعل الامتيازات العادية/الخاصة بالمسؤول واضحة)، ولكنه يقتصر على حالة واحدة محددة جدًا:

إذا كانت هناك حالات أخرى محددة جيدًا ومربكة غالبًا على موقعك، فقد يكون من الممكن إنشاء مكونات سمات مماثلة لعرض تحذيرات قبل اتخاذ إجراءات خاصة بالمسؤول.

7 إعجابات

نعم، بالضبط. أعتقد أن هذا يأتي جزئيًا من سنوات العمل كمسؤول نظام، وفكرة “أقل امتياز ضروري” التي ترسخت في ذهني من خلال الخبرة العملية. ( rm -rf كـ root في المكان الخطأ على نظام إنتاجي هو طقس من طقوس العبور!)

6 إعجابات

هذا يثير اهتمامي أيضًا. حلي الحالي هو استخدام كل من كروم وإيدج. في كروم لدي حساب المسؤول الخاص بي، ولكن في إيدج أنا في حساب المسؤول وأنا أنتحل شخصية حساب مستخدم لديه بريد إلكتروني منتهي الصلاحية. انتحال الشخصية هو فقط لأنني لا أريد التحدث إلى قسم تكنولوجيا المعلومات.

في وضعك، يمكنك إنشاء تسجيل دخول ثانٍ، والحصول على متصفح واحد للمسؤول، ومتصفح واحد للمستخدم. ليس مثاليًا ولكنه كان جيدًا بما فيه الكفاية بالنسبة لي.

5 إعجابات

إليك مثال جيد على مكان فائدة هذا:

لا أريد أن أتمكن من انتهاك قواعد العلامات المقصودة عن طريق الخطأ. (هل يمكن للمشرفين غير الإداريين أيضًا القيام بذلك عن طريق الخطأ؟ لا يمكنني الاختبار بسهولة، حتى.)

يمكنني إنشاء حساب إداري منفصل وتقليل حسابي الرئيسي إلى مستخدم عادي، لكنني أخشى أن أفوت إشعارات الأعلام والرسائل المهمة.

4 إعجابات

هذا شيء يتعامل معه المتصفح نفسه، انظر

4 إعجابات

هل هذا يبدو وكأنه يسمح لي بتبديل ملفات تعريف المتصفح بالكامل؟ لا يبدو أن هذا يساعد، إلا إذا قمت بإنشاء حساب مستخدم Discourse مختلف تمامًا للاستخدام الإداري.

أم أنني أفتقد شيئًا ما. على سبيل المثال، حسابك يا @codinghorror مدرج كمسؤول هنا، لذا أفترض أنه ما لم تكن تفعل شيئًا لم أفهمه تمامًا، فأنت تعمل في وضع المسؤول الآن. لكنك تعمل أيضًا كمستخدم للموقع. ألا تواجه أشياء حيث (على سبيل المثال) تنشئ عن طريق الخطأ منشورات لا تتبع قواعد العلامات المكونة؟ (لقد فعلت ذلك أكثر من مرة عن طريق الخطأ…)

إعجابَين (2)

ليس حقًا – جزء من كونك مسؤولاً هو فهم المسؤولية التي تتحملها والحدود التي يجب أن تحترمها. إذا لم تتمكن من القيام بذلك، فلا يجب أن تحتفظ بامتيازات المسؤول.

لكنني أيضًا متعاطف مع الأشخاص الذين يريدون أن يكونوا آمنين للغاية وأوصي باستخدام حسابين وتسجيل الدخول كمستخدم عادي عندما يحتاجون إلى التأكد تمامًا. وباستخدام دعم ملف تعريف المتصفح المدمج، يصبح هذا سهلاً للغاية.

7 إعجابات

حسنًا، الأمر أشبه بالتشغيل بصلاحيات المستخدم الجذر (root) على نظام لينكس (Linux) طوال الوقت. الأمر لا يتعلق فقط باحترام الحدود، بل بعدم تجاوزها عن طريق الخطأ عندما لا تدرك وجودها. بعض الأشياء، مثل الدخول إلى الإعدادات، لن تحدث عن طريق الخطأ، ولكن يبدو أن هناك الكثير من الأشياء الصغيرة التي يتجاوز فيها المسؤول (admin) التكوين دون أي إشارة إلى وجود شيء يتم تجاوزه..

كما ذكرت أعلاه، فإن وجود حساب ثانٍ ليس جيدًا حقًا، لأنني لن أرى إشعارات هذا الحساب إلا بشكل متقطع.

6 إعجابات

أتفهم القلق، لكنه ليس مشكلة كبيرة من الناحية العملية، على الأقل ليس على مدار السنوات العشر التي عملت فيها على هذا المشروع.

(ضع في اعتبارك أيضًا أننا نقوم بإلغاء صلاحيات الموظفين تلقائيًا ونطلب إعادة التحقق من البريد الإلكتروني للموظفين الغائبين لفترة طويلة، مما يصلح معظم هذا تلقائيًا في رأيي)

إعجاب واحد (1)

مرحباً مات!
لإضافة بعض التفاصيل، فإن إمكانية قيام مستخدم إداري بالتصرف كمستخدم عادي ستضيف بُعدًا إضافيًا لجميع منطق تفويض المسؤول بالكامل.

على الرغم من أن هذا المنطق مركزي في الغالب في guardian.rb و /lib/guardian/*.rb، فإن التعقيد واحتمالية الأخطاء لمثل هذا التغيير ستكون كبيرة جدًا، وستحتاج ضرورة هذه الميزة إلى تفوق ذلك بكثير، وهو ما لا يحدث، نظرًا للبدائل.

إعجاب واحد (1)

هل سيكون من الممكن النظر في “حماية” أكثر استهدافًا لبعض الأشياء التي يمكن أن تحدث عن طريق الخطأ؟ مثل إعداد: “يجب على الموظفين اتباع قواعد وضع العلامات على الفئات”؟ بصراحة، هذا وحده سيحل معظم المشكلة العملية التي أواجهها.

أو… أجد الأمر غريبًا بعض الشيء أن أشياء أخرى مثل طول المنشور لا تزال محمية حتى للمسؤولين… ربما في الواقع هذه المسألة بالذات هي مسألة جعل ذلك الطريقة التي تعمل بها الأمور بدلاً من إضافة خيار؟

إن إضافة طول المنشور ستتطلب تغيير قاعدة البيانات بأكملها. هناك حد أقصى لعدد الأحرف التي يمكننا تخزينها في قاعدة البيانات لكل حقل.

هذا يبدو غير منطقي بالنسبة لي ولكني قد أكون أفتقد شيئًا ما. أعني:\n\n* إذا كنت مسؤولاً، وحاولت نشر منشور أقصر من min post length، فستظهر لي رسالة الخطأ العادية ولا يمكنني المتابعة.\n* إذا كنت مسؤولاً، وحاولت النشر بدون علامات في فئة تتطلب واحدة، فسيسمح لي بالمتابعة.\n\nما الذي يتم تخزينه في قاعدة البيانات هنا؟

3 إعجابات

عذرًا، كنت أعني فقط طول المنشور/العنوان - يوجد حد أقصى لطول محتوى المنشور في حقل قاعدة البيانات الفعلي الذي يتم تخزينه فيه. هناك قاعدة مماثلة لعنوان المنشور، وهو الحد الأقصى لعدد الأحرف المخصص لهذا الحقل المحدد في قاعدة البيانات.

لذا، إذا قرر مسؤول، “حسنًا، أريد منشورًا مكونًا من 900,000 حرف” أو “حسنًا، أريد منشورًا بعنوان مكون من 500 حرف” فهذا غير ممكن دون تغيير قاعدة البيانات.

إنها مجرد تفصيلة فنية، ولكن بما أنك ذكرت طول المنشور، فقد كنت أفكر في الأمر.

إعجاب واحد (1)

آه حسناً. نعم، هذا هو عكس المشكلة التي أقلق بشأنها تمامًا :slight_smile:

أفترض أن OP قصد العمل معظم الوقت كمستخدم عادي. بالنسبة لي، أريد أن أشعر بنفسي كمستخدم بسيط أيضًا:

  • أزرار أقل
  • لا وصول إلى إجراءات المشرف/المسؤول
  • استخدام حالات استخدام بسيطة

بعد الترقيات أو التعديلات، أود التفاعل مع المنتدى كما يراه المستخدم العادي لتجنب سوء الفهم.

بالنسبة لمجتمعي، وضع المسؤول ضروري فقط للترقيات أو الاختبارات مع الإضافات وواجهة المستخدم. لا حاجة لأن أكون مشرفًا طوال الوقت أيضًا. أعتقد أيضًا أنه بالنسبة لبعض الأشخاص مثلي، فإن التبديل المؤقت إلى وضع المسؤول أفضل من وجود حسابين.
كتب OP عن sudo. هذا هو نفس الشيء تقريبًا ولكنه معكوس. عادةً ما أقوم بالتبديل مؤقتًا إلى مجهول للتحقق من بعض الحالات. على أي حال، سيكون من الرائع أن يكون هناك خيار خفيف لتفعيل وضع المسؤول مثل “انتحال شخصية” تحت حساب عادي خاص.

6 إعجابات

يذكرني هذا بشيء حدث قبل أيام قليلة. أنا في طور ترحيل منتدى.

لقد منحت صلاحيات المسؤول للمسؤول في المنتدى القديم.
وهو مستخدم لـ Discourse في منتدين آخرين، وهو أيضًا مشرف. لذا فهو يعرف القليل عن واجهة Discourse والتنقل فيها.

من حسابه الإداري (لم أكتب له أي إرشادات، تركته يكتشف الأشياء بنفسه) أخبرني أنه فوجئ برؤية أنه يستطيع الوصول إلى الرسائل المباشرة من أشخاص آخرين؛ لقد نقر بشكل عشوائي على صفحة ملف شخصي عام ورأى قائمة بالرسائل المباشرة، مما فاجأه.

أخبرني أنه فكر فجأة “حسنًا، يبدو أنني في مكان لا ينبغي أن أكون فيه” (للتوضيح: لا ينبغي أن يكون هنا إذا لم يكن لديه غرض إداري/إشرافي في هذا الوقت).

ليس لديه فكرة أنه يمكنه الوصول إلى هذه الرسائل من الواجهة بسهولة كما تصل إلى رسائلك المباشرة الخاصة من ملفك الشخصي.

وقد حدث لي أيضًا قبل بضعة أسابيع، على الرغم من أنني كنت مسؤولاً عن منتدى Discourse منذ عام 2018… :sweat_smile:

في رأيي، في علامة التبويب “الرسائل المباشرة” من الملف الشخصي العام للمستخدم، كمسؤول، يجب أن يكون هناك رمز أو أي نوع من التحذير بأن النقر عليه هو إجراء إشرافي أو إداري، حيث سترى أشياء مخصصة لتكون “خاصة” (في 99٪ من عقول المستخدمين على أي حال). :man_shrugging:

5 إعجابات

لذلك… لقد فكرت في هذا، وأنا أقل اقتناعًا بأنها تغيير كبير بعد كل شيء. بالتأكيد، هناك الكثير من المنطق المتناثر، لكن ألا يعود الأمر كله إلى التحقق من is_admin أو is_staff؟

سيحتاج “sudo” فقط إلى إضافة تبديل “staff_mode”، ويمكن لدالتي is_staff و is_admin التحقق من حالة هذا التبديل و علامة user.admin أو user.staff. (بالطبع، ستحتاج تنشيط التبديل إلى فحص خاص ينظر فقط إلى قيمة user.admin أو user.staff.)