هل تعرف ما إذا كان هذا يعمل مع إضافة ActiviyPub؟
لم أختبر ذلك. تتجاوز هذه الإضافة عمليات التحقق من الوصول والرؤية، لذا فهي تعمل بشكل جيد بشكل عام مع الإضافات الأخرى. يمكنني أن أتخيل أن إضافة ActivityPub تتصل بأماكن تتجاوز هذه الشيكات (عن غير قصد). الطريقة الوحيدة لمعرفة ذلك هي اختبارها.
ومع ذلك، لا أرى حالة استخدام حيث تكون فئات المواضيع الخاصة مؤهلة لـ ActivityPub.
إعجابَين (2)
أوه، فهمت. أسأت فهم ما يفعله هذا.
حسنًا، هذا أفضل.
إعجابَين (2)
شكراً لك على هذه الإضافات الرائعة، لقد افتقدناها منذ فترة طويلة.
لقد حاولنا ربطها بميزة “البريد الوارد”. إنها تعمل بشكل جيد في الحالات البسيطة، لكن الحالات الأكثر تعقيدًا لا تعمل بشكل جيد جدًا:
- إذا أرسل شخص ما بريدًا إلكترونيًا إلى فئتين “خاصتين” من فئات المواضيع، فسيظهر في فئة واحدة فقط (وهو أمر طبيعي في طريقة عمل ديسكورس، ولكنه غير مفهوم للأشخاص الذين يستخدمون البريد الإلكتروني)
- نفس الشيء إذا أرسل المستخدم إلى عدة رسائل بريد إلكتروني مرتبطة بالمجموعات وأخرى بالفئات
- إذا أرسل المستخدم إلى رسائل بريد إلكتروني خارجية وإلى البريد الإلكتروني لفئة “الموضوع الخاص”، فعند الرد، لا تتلقى رسائل البريد الإلكتروني الخارجية الأخرى الرد. (تدعم رسائل المجموعات هذا، لأننا نستطيع دعوة شخص ما إلى المحادثة)
هذه المشكلات ليست خاصة بهذا المكون الإضافي ولكنها عيب عام لمواضيع الفئات مقابل صناديق الوارد للمجموعات. لا يهدف هذا المكون الإضافي إلى حل كل هذه المشكلات.
إعجاب واحد (1)
إصلاح: تمكن البحث الدلالي لـ Discourse AI من تجاوز الحماية. تم حل هذه المشكلة الآن. إذا كنت تستخدم هذه الإضافة مع إضافة Discourse AI، فتأكد من التحديث!
3 إعجابات
رأيت هذا المكون الإضافي للتو. رائع جداً.
إعجاب واحد (1)
شكراً على الإضافة @RGJ، يبدو أنها تلبي الميزة التي أحتاجها. 
هناك مشكلتان واجهتني أثناء اختبارها:
- إذا قمت بـ “فتح” فئة موجودة أ (حتى الآن يمكن الوصول إليها فقط للمجموعة أ) عن طريق تفعيل مربع الاختيار “تمكين المواضيع الخاصة” ضمن إعدادات الأمان وإضافة حقوق لمجموعة أخرى ب لتكون قادرة على نشر مواضيعها الخاصة، يبدو أن جميع المواضيع الموجودة من قبل مستخدمين آخرين من المجموعة أ يمكن رؤيتها من قبل أعضاء المجموعة ب. لذلك يبدو أن ميزة الموضوع الخاص تعمل فقط للمواضيع التي تم إنشاؤها بعد تفعيل الإضافة، ولكن ليس للمواضيع الموجودة التي تم إنشاؤها قبل تفعيل الإضافة. هل يمكن لأحد تأكيد ذلك؟
أنا أتوقع/أرغب في أن تظل المواضيع الموجودة مخفية/تصبح مخفية لمستخدمي المجموعة ب (كما تعمل للمواضيع الجديدة). بخلاف ذلك، لست متأكداً من كيفية الترحيل. - أثناء الاختبار، لاحظت أنه بعد إنشاء موضوع من قبل مستخدم ينتمي إلى المجموعة أ (مالك الفئة)، ظهر عداد
جديد (1)في عرض الفئة لمستخدم من المجموعة ب. نظرًا لأن الموضوع كان مخفيًا (بشكل صحيح) للمستخدم، يبدو هذا الإشعار بواسطة العداد خطأً وقد يربك المستخدمين.
discourse 3.2.0.beta5-dev (cef6aca6e5)
plugin 1.5.3 (709df2c)
لا يؤثر المكون الإضافي على المواضيع التي تم إنشاؤها بعد تمكين المكون الإضافي فحسب، بل يعمل أيضًا على جميع المواضيع في تلك الفئات.
لست متأكدًا مما
يعنيه. إذا كان الأمر يتعلق بمحدد المجموعة الموجود أسفل مربع الاختيار، فهذا ليس ما تفعله هذه الإعدادات.
المواضيع مرئية لبادئ الموضوع وللمستخدمين في المجموعات التالية
عندما تضيف المجموعة B هناك، فإنك تمنح جميع أعضاء المجموعة B القدرة على عرض جميع المواضيع. هذا مخصص، على سبيل المثال، لفريق الدعم الخاص بك.
إذا لم يكن الأمر يتعلق بمحدد المجموعة هذا، فيرجى وصف إعداداتك بمزيد من التفصيل.
عذرًا، لقد عبرت عن نفسي بشكل سيء.
لم أضف المجموعة ب هناك. لقد أضفت المجموعة ب فقط إلى إعدادات الأمان العامة للسماح لهم برؤية الفئة والمواضيع المنشورة.
وصف إعداد أكثر تفصيلاً:
إعدادات الفئة قبل تمكين المكون الإضافي:
- المجموعة أ فقط لديها حق الوصول إلى الفئة (عرض، رد، نشر).
إعدادات الفئة بعد تمكين المكون الإضافي:
- إضافة حق الوصول للمجموعة ب إلى الفئة (عرض، رد، نشر)
- تمكين المواضيع الخاصة لهذه الفئة
- إضافة المجموعة أ إلى المواضيع مرئية لبادئ الموضوع وللمستخدمين في المجموعات التالية: (في الواقع، تمت إضافتها بالفعل افتراضيًا)
أولاً، لقد قمت للتو بدفع إصلاح لـ Ember5، ولكن هذا لا ينبغي أن يؤثر على عمل المكون الإضافي. للتأكد بنسبة 100%، يرجى إعادة بناء المكون الإضافي وتكوينه من البداية.
لا يمكنني تكرار هذا.
- قم بإعداده كما قلت، مع المستخدم A في المجموعة A والمستخدم B في المجموعة B.
- قام المستخدم A بنشر مشاركة
- قم بإعداد المكون الإضافي
- قام المستخدم B بنشر مشاركة
- قام المستخدم A بنشر مشاركة أخرى
عرض المسؤول
المستخدم A يرى
المستخدم B يرى
لذلك هذا يتصرف كما هو متوقع.
أيضًا، هذا غريب جدًا، لا يوجد إضافة مجموعة افتراضية هناك.
إعجاب واحد (1)
شكراً على ملاحظاتك واختبارك السريع، @RGJ! وأعتذر عن الرد المتأخر، فقد أبقتني بعض المهام الأخرى بعيداً عن المشكلة لبضعة أيام. قمت بتحديث المكون الإضافي وأعدت الاختبار بفئة أخرى. لا يمكنني إعادة إنتاجه بنفسي الآن، لذا يبدو أنه يعمل كما هو متوقع. يتم عرض الموضوعات التي بدأها مسؤول فقط في الفئة (ربما عن قصد ومنطقي)، ربما خلطت بين ذلك في اختباري الأول. آسف على الإزعاج!
تبدو المشكلة المتعلقة بعداد “جديد” للموضوعات الجديدة مستمرة: لدى المستخدم في مجموعة مسموح له فقط برؤية خيوطه الخاصة عداد “جديد”، ولكنه لا يستطيع رؤية الخيوط الجديدة، إذا نشر مستخدم من مجموعة “الدعم” (مسموح له برؤية جميع الموضوعات) موضوعاً جديداً. انظر لقطة الشاشة أدناه: “Neu (5)” للمستخدم بدون حقوق
عرض لمستخدم الدعم ذي الحقوق:
إعجاب واحد (1)
صحيح، يتم التحكم في ذلك بواسطة الإعداد private topics permitted groups “عرض المواضيع التي بدأها عضو في هذه المجموعات دائمًا”
نعم، إنها مشكلة معروفة. طلبات السحب أو الإشارات مرحب بها.
إعجاب واحد (1)
سؤال واحد، حتى لو كنت أعرف الإجابة.
ماذا يحدث إذا كان يجب تعطيل المكون الإضافي، بسبب بعض التعارضات وما إلى ذلك. هل ستكون عندها كل المواضيع والمنشورات مرئية للجميع أم سيتم تقييد تلك الفئة للجميع؟
لأن الخيار الأول هو شيء لا يمكنني قبوله على الإطلاق، الكثير من البيانات الحساسة. ولكن إذا كان الثاني… يمكنني التعايش معه.
عند تعطيل المكون الإضافي، ستكون جميع المواضيع في الفئة مرئية للجميع.
إذا كنت ترغب في تجنب ذلك، يجب عليك تعديل أذونات الفئة لتكون أكثر صرامة، قبل تعطيل المكون الإضافي.
إعجاب واحد (1)
كما توقعت. لذا، هناك خطر كبير واحد: الخطأ البشري. إذا اضطررت إلى تعطيله، فيجب أن أتذكر تعديل قيود المجموعة أيضًا في تلك الفوضى. هذا سؤال كبير حقًا في الواقع.
تجنب الفوضى وستكون بخير 
إعجاب واحد (1)
هذا صحيح جداً 
ولكن قضايا المكونات الإضافية والبيئة خارجة عن إرادتي (وإلا لكانت… مثيرة 
)
أنا فقط ألعب بالفكرة… إذا كان هناك بعض الإجراءات الأمنية، مثل مكون مصاحب له وظيفة واحدة وفريدة من نوعها: مراقبة حالة المكون الإضافي وإبلاغ المسؤول (المسؤولين) فورًا بأن الفئة مرئية للعالم.
أنا لاعب صغير، لكنني أتساءل فقط ما إذا كانت تلك المنتديات القائمة على الشركات، التي تستخدم هذا، وغالبًا ما يكون لديها أكثر من مسؤول واحد، على دراية كاملة بهذا الخطر 
إعجاب واحد (1)
دون معرفة الكثير عن الاحتمالات، وبالتالي ربما مجرد فكرة غير ذات صلة، كيف يمكن التخفيف من المخاطر: قبل/أثناء تعطيل المكون الإضافي، اعرض حوارًا للمستخدم، يذكره بعواقب تعطيل المكون الإضافي والتحقق مرة أخرى من إعدادات أمان الفئة.
مجرد رأيي (2 سنت): بشكل عام، أفترض أن المشكلة بسيطة نسبيًا، حيث أفترض أن الأشخاص لن يقوموا بتعطيل مكون إضافي يحتاجون إليه بشكل أعمى، ولكنهم سيفكرون في كيفية تلبية متطلباتهم إذا احتاجوا إلى تعطيل المكون الإضافي…
السبب الأكثر شيوعًا هو تعطل المنتدى. ولا أعرف الكثير من المسؤولين الذين يستمرون في التفكير عندما يعرفون ما هو السبب ويكون الحل هو تعطيل إضافة. أحب Category Lockdown ولكن نظرًا لأنها معطلة، فقد قمت بإزالتها في ثانية واحدة. عند هذه النقطة، يجب أن أتذكر الآن ما هي قيود إضافة معينة تصرفت بشكل جيد لفترة طويلة.
هذه هي نفس مشكلة النسخ الاحتياطي. كلنا نعرف مدى أهمية النسخ الاحتياطي. ولكن إذا كان يعتمد على العمل اليدوي والتذكر … فلا توجد نسخ احتياطية أو أنها قديمة جدًا.
العامل البشري هو أكبر خطر على الإطلاق.
على أي حال. الإضافة نفسها رائعة ولكن يجب أن أفكر قليلاً في الإيجابيات والسلبيات. أنا أخضع للوائح مختلفة والكشف عن هذه البيانات يمكن أن يكون مكلفًا بأكثر من طريقة واحدة.
إعجابَين (2)