هذا يشبه موضوع #ميزة - #تطوير، لست متأكدًا في أي منهما يجب أن يكون.
هل هناك طريقة لتعديل إعدادات الموقع في إضافة (plugin)؟ أنا متأكد بنسبة 99% من عدم وجودها، ولكني أود فقط التأكد من ذلك.
إذا لم تكن موجودة، هل يمكنني تقديم اقتراح لعدم جعلها غير قابلة للتغيير (immutable)؟ أو ربما، وجود واجهة برمجة تطبيقات (API) أو طريقة لـ “فتح” الخاصية غير القابلة للتغيير لـ SiteSettings، ربما؟
إحدى حالات الاستخدام المحتملة التي أبحث عنها هي تضمين قائمة بالفئات المحمية في إعداد ما بحيث يسهل على المسؤول تضمينها/استبعادها.
هل يمكنك أولاً وصف حالة الاستخدام من وجهة نظر المجتمع؟ ما الذي يحاولون تحقيقه وما الذي يجعل القيام بذلك صعبًا في الوقت الحالي؟ ما هي الميزة التي تتخيل أنها ستحل حاجتهم بشكل أكثر فعالية (بغض النظر عن كيفية تنفيذها)؟
بعد ذلك، يمكننا المتابعة من هناك لتحديد ما إذا كان هذا هو الأفضل تنفيذه في إضافة (plugin) أم كميزة أساسية (core feature).
بعد ذلك، يمكننا المتابعة من هناك لمناقشة اقتراحات حول كيفية تنفيذه.
لقد افترضت خطأً أنه بما أن الإعدادات غير قابلة للتغيير في إعدادات الموقع (TCs)، فهي كذلك أيضًا في الإضافات (plugins) في Ruby. سأجرب ذلك.
سيكون من الجيد جعلها قابلة للتحرير في إعدادات الموقع. حالة الاستخدام الخاصة بي (والتي أستخدم إضافة لها الآن) هي أنني آخذ جميع المواضيع والمنشورات في جميع الفئات افتراضيًا وأقوم ببعض الإجراءات عليها، ولكنني لا أرغب في تضمين الفئات المحمية (مثل إعداد excluded_categories).
ومع ذلك، إذا كان من الممكن إضافة فئات محمية إلى الإعداد، ثم الوصول إليها بعد ذلك، فسيكون الأمر أسهل. بهذه الطريقة، يمكن للمسؤولين تضمين بعض الفئات المحمية إذا أرادوا ذلك عن طريق إزالتها من الإعداد.
باستخدام فكرة @pfaffman، يمكن القيام بذلك على الأرجح، ولكن ليس في إعدادات الموقع.
المشكلة في هذا هي أنني لا أعرف الفئات المحمية مسبقًا.
أود معرفة المزيد. أعتقد أنه سيساعدني في وضع هذا الطلب في سياق أفضل.
هل أنت على استعداد لمشاركة المزيد عن مجتمعك؟
هل أنت المستخدم الأساسي لهذه الميزة أم أن هناك آخرين في فريقك يحتاجون إليها؟ هل لديك وثائق موجهة للمستخدمين لسير العمل الذي يعتمد على هذه الميزة؟ إذا كان الأمر كذلك، فكيف تبدو؟ إذا لم يكن كذلك، هل يمكنك وصف بإيجاز كيف قد تبدو؟
أنا أطور إضافة (plugin) تأخذ المواضيع والمنشورات وتنشرها على GitHub كملفات Markdown (كأرشيف).
ومع ذلك، لا أرغب في تضمين الفئات الخاصة (أعتقد أن هذا هو المصطلح الصحيح الآن؟) في هذا، لأنها “خاصة”.
لذلك، أبحث عن طريقة لملء إعداد مسبقًا بقائمة الفئات الخاصة، والتي لا يمكن تعريفها ضمن المعامل default، لأنني لن أعرف ما هي الفئات الخاصة مسبقًا.
في حال كان من الممكن القيام بذلك عن طريق تغيير SiteSetting مباشرة في Ruby، فهل يمكن فعل الشيء نفسه باستخدام settings الخاص بمكون الثيم (Theme Component)؟ أنا متأكد تمامًا من أن الأخير غير قابل للتغيير (immutable). هل هناك أي طريقة لتغييره في مكون ثيم؟
ما زلت لا أعرف ماذا تعني كلمة خاص بالنسبة لك. هل تعني أنك تريد فقط الفئات المرئية للجميع، أو للمستخدمين المجهولين؟ أم لديك تعريف آخر؟
إذا كنت تريد تلك، فيمكن للإضافة الخاصة بك الحصول عليها فقط، ربما عن طريق بحث تمرر إليه مستخدمًا (أو ربما عن طريق استدعاء حارس)، أو مجرد التحقق من الأذونات.
أو إذا كانت كلمة خاص شيئًا يعتمد على الرأي، فيمكنك إضافة إعداد.
وربما تريد القيام بذلك في مهمة تعمل يوميًا أو ما إلى ذلك؟
إذا كنت تدفع الأشياء إلى github، أعتقد أنك سترغب في أن يقوم discourse بالقيام بذلك بدلاً من العبث بجعل متصفحك يدفع البيانات إلى discourse؟ لا أرى كيف أو لماذا ستقوم بذلك باستخدام مكون سمة.
أعني فئات مثل #staff، وفئات أخرى يقتصر الوصول إليها على مجموعات. أعتقد أن هذا ممكن باستخدام إضافة (plugin)، ولكنني أفترض أنه لا يمكن تعديل إعدادات TC (إعدادات لوحة التحكم) حينها؟
هل فهمي صحيح بأنك تشير إلى الطريقة Category.where(...) للحصول على هذه الفئات “الخاصة”؟ ولكن ماذا لو أراد المسؤول تضمين (بعض من) تلك الفئات - هل أحتاج إلى إعداد include categories يبطل الفئات “الخاصة” المحددة في الكود؟ هل سيكون ذلك مُحبطًا للهدف؟
ما زلت لا أفهم هذا. نعم، يمكنك إضافة تلك الإعدادات في إعداد موقع (SiteSetting) ويمكن للإضافة قراءتها، بل وتغييرها. ولكن لماذا ستحتاج إلى تغيير الإعداد بالنظر إلى السيناريو المذكور أعلاه؟
بافتراض أن لدي 5 فئات: A، وB، وC، وD، وE. لنفترض الآن أن B وC متاحتان فقط لبعض المجموعات. لمنع مشاركة المواضيع الخاصة هنا عند تحميلها إلى المستودع، تتم إضافة B وC إلى الإعداد excluded_categories، إلى جانب فئات أخرى مثل Staff.
الآن بافتراض أن مسؤول الموقع يوافق على مشاركة مواضيع B، يمكنه المضي قدمًا وإزالة B من الإعداد، مع ترك C هناك.
لذلك، سيتعين تغيير excluded_categories في البداية لإضافة الفئات “الخاصة” B وC. لست متأكدًا مما إذا كان هذا منطقيًا؟
على الرغم من أن ذلك ممكن تمامًا من الناحية التقنية، أعتقد أن النهج سيكون معقدًا للغاية، خاصة وأن “في البداية” يصعب تحديده/اكتشافه، وأنت تريد تجنب أن يستمر المكون الإضافي في إضافة B مرة أخرى بعد أن قام مسؤول الموقع بإزالته. أيضًا، عند إضافة فئة خاصة جديدة، سيحتاج المكون الإضافي إلى إضافتها، ولكنه سيحتاج إلى أن يكون قادرًا على رؤية الفرق بين فئة جديدة (إضافة) وفئة تمت إزالتها مسبقًا بواسطة المسؤول (عدم إعادة الإضافة).
أنا أميل إلى اختيار إعداد include_private_categories يبدأ فارغًا، وسيقوم المكون الإضافي ببساطة بمعالجة جميع الفئات العامة، والفئات الموجودة في include_private_categories. سيوفر لك ذلك صداعًا أقل بكثير.
تصميم بديل آخر يمكنني تخيله هنا هو وجود مستودعين منفصلين: أحدهما للمحتوى العام والآخر للمحتوى الخاص.
يمكن الاحتفاظ بمستودع المحتوى الخاص خاصًا (يمكنك تحديد من لديه حق الوصول إليه بشكل مستقل).