سلوك سيء في دفع موضوع قديم ولكن لم أتمكن من العثور على موضوع أحدث. لا تتردد في إرشادي.
أنا أستخدم المنتدى للعديد من الأشياء الغريبة هذه الأيام.
أميل إلى إنشاء فئات للقراءة فقط لأغراض خاصة مع مستخدم وصول واحد فقط (للحفاظ على البساطة لكل من لا يريد إنشاء حساب فعلي). في بعض الأحيان ينشئ المستخدم حسابًا ويُسمح له أيضًا بحقوق الكتابة. باستثناء أنني أحتاج على ما يبدو إلى مجموعة category_xyz_see و category_xyz_write لتحقيق ذلك. حسنًا، هذا مجرد عمل.
يبدو غريبًا بطريقة ما أنه يمكنك فقط إضافة مجموعات ضمن الأمان ولكن لا يمكن إضافة مستخدم، وهو في النهاية مجرد كائن آخر.
لم أجرب نهج الدعوة (خلف SSO حتى لو تم إصلاحه على الأرجح الآن).
باستثناء أنني أستخدم هؤلاء المستخدمين الذين تم إنشاؤهم خصيصًا والذين يمكنهم الوصول إلى الفئات الخاصة.
السبب وراء ذلك هو أن الناس حقًا لا يريدون إنشاء حساب آخر “في مكان ما” هذه الأيام. لذا بالنسبة للمعلومات قصيرة العمر، أشهر أو عامين كحد أقصى، أستخدم إما تسجيل دخول لديه حق الوصول للقراءة إلى المناطق العامة في الموقع أو تسجيل دخول محدد يصل إلى فئة مغلقة.
يبدو أن هذا النهج يجلب المزيد من القراء ويتحول البعض إلى مستخدمين فعليين إذا وجدوا أشياء أخرى مثيرة للاهتمام في الموقع.
وجود تسجيل دخول مطلوب يحافظ على نظافة الموقع.
أكتب هذا فقط كسيناريو حالة استخدام لكيفية استخدام شخص ما لـ Discourse الخاص به، لا أكثر. كمطور، أهتم عادةً عندما يفعل الناس أشياء لم أتخيلها.
ولكن نظرًا لأنه يمكن حل ذلك عن طريق إضافة مجموعة أخرى بحقوق مختلفة حيث تضيف المستخدمين المطلوبين، فهذا ليس بالأمر الكبير.
أعتقد أن هذه فكرة مثيرة للاهتمام. لقد سعينا بشكل عام إلى تحقيق التكافؤ مع المستخدمين للمجموعات. هذه هي المرة الأولى التي أرى فيها العكس.
بالنسبة للمواقع الصغيرة جدًا أو للفئات المخصصة لعدد قليل من الأشخاص فقط، يمكنني أن أرى أنها مفيدة جدًا وسريعة لتتمكن من وضع أسماء المستخدمين في حقول أمان الفئة جنبًا إلى جنب مع أسماء المجموعات. ولكن من الواضح أنه بمجرد البدء في إضافة الكثير من أسماء المستخدمين، يصبح الأمر غير عملي.
أعتقد أنني أختلف مع ستيفن هنا، من وجهة نظر المبرمج على الأقل. سواء كان لديك مستخدم أو مجموعة أمر غير ذي صلة، فكلاهما كائنات. كما أرى، كلاهما يتداخلان ويمكن أن يكون لهما تداخلات.
هل سيكون مربكًا في واجهة المستخدم، ربما. ربما لا. لا نحتاج إلى إظهار التداخل ووجود مستخدم أيضًا في مجموعة أمر غير ذي صلة (يعود الأمر للنظام لمعرفة ذلك).
لقد واجهت أيضًا قيدًا مفاده أن الفئة الفرعية يجب أن تتمتع بوصول على مستوى الفئة الأم. وهذا منطقي إلى حد ما. أعتقد أنني أستطيع عكس كل شيء ولكن في هذه الحالة بالذات سيبدو الأمر عكسيًا.
سأعرض حالة الاستخدام الفعلية مرة أخرى، من الأسهل شرح الأسباب. قد لا أعرف كل الكلمات الإنجليزية المناسبة هنا ولكن أعتقد أن الناس سيفهمون المغزى.
مات شخص ما وهناك الكثير من الأشخاص في التركة.
تم إنشاء مستخدم للقراءة فقط لسهولة الوصول (تمت إضافة هذا المستخدم إلى مجموعة “رؤية”).
تمت إضافة بعض الأشخاص الموجودين بالفعل في الموقع إلى المجموعة (لذلك لن يضطروا إلى تسجيل الخروج وتبديل الحسابات).
تحتوي الفئة العلوية على معلومات مشتركة، دفن، إلخ.
تحتوي فئة فرعية واحدة على معلومات مالية (لا تزال غير واضحة، لذلك لم يتم إصدارها للجميع حتى يتم حل جميع المشكلات). إضافة رجل موثوق به هنا (يمكن أن يكون خارج التركة) لا يعني أنه سيحتاج (أو حتى يجب أن يكون لديه) وصول إلى الفئة العلوية.
أنا متأكد من أنني أستطيع التوصل إلى طريقة جيدة للتعامل مع الأمر بقليل من التفكير. ولكن بشكل أساسي، السماح بإضافة مستخدمين فرديين إلى أي مستوى سيحل الأمر بشكل أجمل (ومنطقي).
وكل هذا قابل للتحقيق تقريبًا باستخدام مجموعات إضافية لذلك ربما لا يستحق الجهد.
مفاهيم المجموعات والفئات مدمجة في ديسكورس وتلمس العديد من الأشياء، لذلك لست متأكدًا من وجود رغبة في تغيير هذا. سيكون تغييرًا هائلاً.
ومع ذلك، أتفق على أن هذا كان دائمًا مجالًا يجعل ديسكورس يبدو معقدًا للإعداد والإدارة، حتى عند مقارنته بالأنظمة القديمة مثل مجموعات ياهو أو القوائم البريدية.
لدينا بالفعل بعض المجموعات الخاصة التي تحصل على معالجة خاصة، على سبيل المثال مستويات الثقة و الجميع و المشرف/المسؤول. ربما يمكننا أيضًا السماح بإنشاء مجموعات خاصة تُستخدم فقط للوصول إلى الفئات خلف الكواليس، مباشرة من إعدادات أمان الفئة؟ شيء مثل:
للفئة foo:
توفير واجهة مستخدم لاختيار المستخدمين ومنحهم حق الوصول للعرض والرد والإنشاء
عند تحديد المستخدمين، قم بإنشاء مجموعات foo_see و foo_reply و foo_create وأضف المستخدمين إليها
توفير واجهة مستخدم لإزالة المستخدمين وتغيير حق الوصول الخاص بهم للعرض والرد والإنشاء
إذا تم تمكين الإشراف على الفئة، اسمح أيضًا بتحديد المستخدمين كمشرفين على الفئة وإنشاء مجموعة foo_moderator لذلك.
مجموعات الوصول foo غير مرئية من صفحة /groups أو مقترحة مع @ في المنشئ
مجموعات الوصول foo مرتبطة بفئة foo محددة ولا يمكن استخدامها للوصول إلى فئات أخرى
يمكن منح الفئات الفرعية لـ foo حق الوصول تلقائيًا إلى foo بدلاً من معالجة الأخطاء الدائرية الحالية، والتي مربكة
ما يعجبني في هذا هو أنه يمكننا أيضًا الكشف عن واجهة مستخدم عند النظر إلى فئة لمعرفة أسماء كل من لديه حق الوصول إلى الفئة، والأشخاص الذين لديهم حق الوصول للعرض والرد والإنشاء. لطالما شعرت أن هذا كان فجوة. حاليًا، المعلومات البرمجية الوحيدة التي نقدمها هي: القفل: للإشارة إلى أن الفئة آمنة - لا نعرف من لديه حق الوصول.
من خلال وضع هذه الوظيفة ضمن إعدادات الفئة، نقوم أيضًا بتبسيط كيفية إنشاء الفئات والمجموعات. هذا يفتح الباب أمام السماح للمزيد من المستخدمين بإنشاء وإدارة الفئات الآمنة. يمكن أن تكون هناك حتى مجموعة foo_owner للأشخاص المسموح لهم بإدارة الوصول إلى الفئة جنبًا إلى جنب مع مسؤولي الموقع.
لست متأكدًا من كيف قد يبدو هذا وقد لا تكون هناك رغبة في تغيير كهذا، لكننا نرحب دائمًا بالعصف الذهني والأفكار الجديدة، ويفضل أن تكون مع نماذج أولية!
مثير للاهتمام. لا يزال الأمر يبدو معقدًا بعض الشيء (ربما لأنه مبني على ما هو موجود وبالتالي فهو ضروري).
تبدو المجموعات مزدحمة بالفعل (ضياع دائم لمن ينتمي إلى ماذا - نعم، تسمية سيئة، أعرف). لذا يجب أن يكون نهج نوع “foo” مرئيًا بشكل أساسي من الفئة. على الأقل مربع اختيار لتحديد ما إذا كنت تريد إظهار تلك الموجودة في المجموعات افتراضيًا.
من المؤسف أن Discourse مبني بأدوات لا أعرفها على الإطلاق. في أفضل الأحوال، قد أقوم بإنشاء أدوات تصل إلى قاعدة البيانات مباشرة. وهو ما يفعله الآخرون بشكل أفضل بكثير باستخدام نصوصهم البرمجية على أي حال. حسنًا، ربما عندما أتقاعد :).