مرحباً بالجميع، لاحظت للتو اليوم أنه لم يعد بإمكاننا القيام بما يلي للفئات المقيدة:
مفتاح الربط > تثبيت الموضوع > إنشاء موضوع لافتة
كيف يدير الآخرون القوالب الخاصة بهم للافتات التي يعيدون استخدامها؟
أنا لا أفهم لماذا قد نرغب في أن تطفو المعلومات المستخدمة في اللافتات حول الفئات العامة المزدحمة، ولكن ربما فاتني شيء ما.
أود أن أسمع سير عمل الجميع الآخر.
إليك طلب السحب (PR) ذي الصلة كمرجع: DEV: Gate read-restricted banner topics by janzenisaac · Pull Request #38496 · discourse/discourse · GitHub
عندما تتغير وظيفة كهذه أو تتم إزالتها، فعادة ما يكون ذلك بسبب اعتبارات أمنية أو تتعلق بالتحكم في الوصول. في هذه الحالة، أصبحت مواضيع اللافتات (banner topics) مقيدة بحيث لا يمكن استخدام المواضيع الموجودة في الفئات المقيدة للقراءة كـلافتات بعد الآن.
ومع ذلك، نحن نناقش حاليًا داخليًا ما إذا كانت هناك سير عمل أفضل أو تحسينات يمكن أن تساعد في حالات الاستخدام المشابهة لحالتك.
في غضون ذلك، تتمثل إحدى الحلول البديلة الممكنة، إذا كان الهدف هو ببساطة تجنب ظهور مواضيع اللافتات في قوائم المواضيع العادية، في إنشاء موضوع اللافتة كـ “غير مدرج” (Unlisted) منذ البداية في فئة عامة بدلاً من فئة خاصة. لن تظهر المواضيع غير المدرجة في قوائم المواضيع أو طرق عرض الفئات للمستخدمين العاديين، ولكن لا يزال من الممكن الوصول إليها عبر رابط مباشر واستخدامها برمجيًا:
للحفاظ على التنظيم، يمكنك أيضًا إضافة وسم مثل #banner ليسهل تحديد موقع تلك المواضيع لاحقًا.
من هناك، يمكنك استخدام إضافة Discourse Automation وتشغيل البرنامج النصي “جعل موضوع لافتة” (Make Banner Topic)، بالإشارة إلى معرف الموضوع غير المدرج. سيؤدي ذلك إلى تحويله إلى لافتة مع إبقائه مخفيًا بشكل فعال عن التصفح العادي.
هذا التعديل يبدو لي غريبًا بعض الشيء.
أولاً، الموظفون الذين يمتلكون سلطة تعديل اللافتات هم نفس الأفراد الذين لديهم إمكانية الوصول إلى هذا الموضوع المقيد القراءة. عندما يختارون تعيين موضوع كـ “لافتة” (banner)، فمن المعقول افتراض أنهم يريدون عن قصد جعل محتواه عامًا، لذلك لا أعتقد أن هذا سيشكل مشكلة أمنية.
ثانيًا، عمليًا، اعتاد الموظفون في موقعنا على صياغة الإعلانات داخل موضوع مقيد القراءة قبل تعيينه كـ “لافتة”.
تكمن المشكلة الأمنية في أنه كان يتم إتاحة محتوى اللافتة للجميع، وليس فقط للمشرفين/المسؤولين. أنا لا أتفق مع افتراضك بأن المسؤولين يدركون أن جميع اللافتات المقيدة بالقراءة سيتم جعلها عامة.
ومع ذلك، أرى حالة الاستخدام والرغبة في عدم تلويث الفئات العامة 
شكرًا لك يا @dax على الحل المؤقت، سأجرب هذا في الوقت الحالي، على الرغم من أنني أفتقد وجود منطقة مخصصة لصياغة الموظفين.
لقد جربت الطريقة الموصوفة أعلاه، ولكن خيار “تثبيت الموضوع” يختفي عند إلغاء إدراجه.
لهذا السبب قلت باستخدام إضافة الأتمتة (Automation plugin) في الوقت الحالي
@Discoursenaut الآن يجب أن ترى خيار “تثبيت الموضوع” (Pin Topic) حتى للمواضيع غير المُدرجة (Unlisted topics) حتى تتمكن من تخطي خطوة الأتمتة (Automation).
هل يمكنك التحقق على موقعك؟
مذهل، هذا مثالي!
هل يمكنكم النظر في تحديث التعليمات هنا (ضمن لافتة قابلة للإخفاء) بأنها يجب أن تكون في فئة عامة ويُقترح إلغاء إدراجها.
أضفت تلك التفاصيل، شكرًا على ذكرها!
لدي قلق مماثل أعربت عنه هنا: https://meta.discourse.org/t/i-just-upgraded-to-the-latest-tag-and-lost-banner-topic/398976، وآمل حقًا أن يستمر عمل الحل البديل الخاص بـ @dax.
في حالتي، كنت قد اخترت سير العمل التالي:
لكن مع النهج الجديد، لا يمكنني إجراء مناقشة طاقم العمل حول اللافتات. 
أعتقد أن مجموعة “الموظفين” يجب أن تظل قادرة على رؤية الردود في المواضيع غير المدرجة.
المشكلة ليست في أن الموظفين لن يجدوا الموضوع، بل في أن الجميع يمكنه قراءة المواضيع غير المدرجة في القائمة. يمكننا كلاهما قراءة هذا الموضوع المخفي دون أن نكون موظفين: Configure API Keys for Google Gemini
نعم، لكنهم سيحتاجون إلى الرابط الخاص به حتى يتمكنوا من العثور عليه في المقام الأول.
يمكن للمستخدمين الحصول على ذلك، على سبيل المثال، من خلال متابعة التصنيف أو لأن شخصًا ما يربط منشورهم أو يستشهد به أو يذكّرهم بـ @. كل إشعار يؤدي إلى حصول المستخدم على الرابط. بالإضافة إلى ذلك، يمكنك ببساطة تجربة معرفات (IDs) أقل من معرف أحدث موضوع تم إنشاؤه. المواضيع غير المدرجة ليست مكانًا للمحتوى الذي لا ينبغي للمستخدمين رؤيته.
في الواقع، وقد ابتكرت حلاً آخر على أي حال:
على سبيل المثال، لجأت مؤخرًا إلى هذا المكون السمة للافتات عبر مجتمعي لأنه لا يتطلب موضوعًا مخصصًا.
