متابعةً للنقاش من كيف أنشئ منشور همسة؟:
يمكن أن تكون الهمسات مفيدة للتوسع، على غرار الوظيفة قيد التطوير حديثًا للردود المعلبة الخاصة بالمجموعة، للسماح أيضًا بهمسات متعددة (خاصة بمجموعات معينة).
مثال:
لدينا @documentation-group يمكنها الاستفادة من الهمسات دون الحاجة إلى الوصول إلى همسات الموظفين أيضًا.
سيكون من المفيد السماح اختياريًا بأكثر من قسم واحد من الهمسات. شكرًا لكم على أي حال للنظر في الأمر.
أعتقد أنه تمت إضافة الوصول الجماعي إلى الهمسات مؤخرًا:
ولكن ستتمكن جميع المجموعات من رؤية جميع الهمسات. أعتقد أن الهمسات المعزولة ستكون إضافة جيدة، على الرغم من أنني لا أعرف مدى صعوبة تحقيق ذلك. 
لا أفترض أن هذا قد تم طرحه بين فريقك في العامين الماضيين؟ 
نحن نبدأ في دمج فرق أخرى في المنصة ترغب في استخدام ميزة الهمس، ولكننا لا نريدهم أن يروا همسات المسؤول لدينا.
أخشى أنه عندما أثرت الأمر، تم اعتباره VeryComplex™، ولم يحظ باهتمام كبير حتى الآن.
قد يكون طلب الميزة هذا مثيرًا للاهتمام كبديل
إنه مشابه ولكنه مختلف. لا أعتقد أننا نريد أن تكون المجموعة الأخرى قادرة على رؤية همسات المسؤول لدينا تحت أي ظرف من الظروف. إليك تصور بسيط نأمل أن يساعد - فكر فيه كطبقات من الهمسات:
إذا كان مكون إضافي أو سمة bbcode لن تؤثر على الهمسات.
في الرابط الذي قدمته، سيكون لديك رمز إضافي متاح في منشور لعرض جزء فقط من المنشور للجميع مع إظهار المحتوى المخفي فقط للمستخدم الأصلي والمجموعة المستهدفة.
الآن، حتى لا يتمكن الأشخاص من عرض مراجعات المنشورات إلا للموظفين.
فكرة حل مثل bbcode ستسمح لك بإخفاء المحتوى داخل منشور لمجموعة أخرى. المثال الوحيد هو ألعاب تقمص الأدوار على الطاولة. ومع ذلك، يمكن للمستخدمين الأذكياء عرضها من خلال استخدام “فحص العنصر” وتغيير CSS.
أعتقد أن #طلب_ميزة واضح تمامًا ويجب أن نكون حذرين بشأن عدم التعامل مع كل شيء كموضوع #دعم والغوص في الحلول البديلة. دعنا نحاول التركيز. 
هل تتخيل أن الفريق الداخلي أ يمكنه رؤية همسات الفريق الداخلي ب؟
أم أن كل فريق داخلي يمكنه فقط رؤية همسات فريقه الخاص؟
أم أن همسة معينة تحتاج إلى تحديد المستلمين بطريقة ما؟
متى تختار استخدام الهمسة مقابل رسالة خاصة (PM) لإدارة المستلمين؟
(الرد بصفتي زميل @putty)
من الناحية المثالية، الخيار الأخير، ولكني أدرك أن تجميع المستخدمين المختلفين في مجموعات مختلفة يمكن أن يكون معقدًا للغاية. الفكرة هي أن لدينا العديد من الفرق الداخلية في شركتنا التي تتطلع الآن إلى بناء تجارب لمستخدميها على منصة Discourse الخاصة بنا أيضًا. يبدو الأمر وكأننا بنينا مجتمعًا رئيسيًا، لكنهم يبنون أيضًا مجتمعات مصغرة بداخله.
مع هذا، يهتم الكثير منهم بالقدرة على استخدام ميزة الهمس في صناديق الوارد والمجموعات الخاصة بهم. المشكلة بالطبع هي أننا لا نريدهم أن يروا الهمسات الإدارية.
حسنًا، أسمعك.
الأمر صعب. الهمسات هي بالفعل أداة خطيرة بعض الشيء لأن الأشخاص الذين يمكنهم رؤيتها عليهم فهم موضوع ما على مستويين، يضيقون لرؤيته من وجهة نظر الجمهور مع رؤية المنظور المميز الذي يشمل الهمسات.
أعتقد أن إضافة طبقة إضافية قد تجعل الأمر مربكًا للغاية لمعظم الناس. أقر بأن البريد الإلكتروني يمنحك هذه الحرية بالفعل حيث تعرض العديد من العملاء سلسلة واحدة بغض النظر عمن يتم إضافته أو إسقاطه من قائمة النسخ على طول الطريق. لكنني رأيت أيضًا أن هذا يؤدي إلى نفس النوع من الارتباك الذي أود تجنبه هنا.
فكرة أعتقد أنها قد تحقق التوازن الصحيح هي جعل رؤية الهمسات تكوينًا على مستوى الفئة. على سبيل المثال:
في هذا النموذج، سيظل بإمكان X و Y رؤية همسات المسؤولين في الفئة أ. لكنني أعتقد أنه يمكنك تحديد الفئات والأعراف بطريقة ستنجح، دون الحاجة إلى إضافة طبقة ثالثة من الهمس داخل موضوع واحد.
ما رأيك في فكرة:
كما وصفها @putty. سيكون هذا حلاً وسطًا رائعًا لأنه، على الأقل في حالتنا، سيكون جميع الأشخاص في “جميع الهمسات الأخرى” موظفين في نفس الشركة. أنا أقفز هنا ولكني أشعر أنني أتعلم تعقيدات المنصة أكثر كل يوم: أفترض أنه إذا كان هذا هو التكوين، فسيكون (على الأقل إلى حد ما) أقل تعقيدًا من منح المجموعات الفردية القدرة على التحكم في من يمكنه رؤية همساتهم؟
سيمنح هذا الموظفين على مستوى الشركة القدرة على الهمس في المجتمع فيما بينهم بغض النظر عن الفئة أو الموضوع أو الرسائل الخاصة. هذا يبدو رائعًا حقًا الآن بعد أن فكرت في الأمر. سيكون هذا رائعًا!
نعم، لست متأكدًا من أي منهما سيكون أكثر تعقيدًا في النهاية للتنفيذ والإعداد. ما زلت قلقًا بشأن وجود مستوى ثالث من المناقشة ضمن نفس الموضوع، على الرغم من ذلك.
يمكنك القيام بذلك اليوم، أليس كذلك؟ طالما أنك على ما يرام مع السماح لجميع الموظفين برؤية الهمسات من المسؤولين أيضًا.
هل يستحق الأمر النظر في قبول هذا القيد؟
ما هي السيناريوهات التي ستحتاج فيها إلى مسؤول للهمس وعدم رؤيته من قبل جميع الموظفين؟ وألن ترغب أحيانًا في أن يتمكن المسؤولون من الهمس لموظفين آخرين إذا كنت تسمح للموظفين الآخرين بالهمس لبعضهم البعض؟ كيف سيعمل ذلك؟
ربما في نموذج “يمكن لجميع الموظفين الهمس فيما بينهم”، يجب على المسؤولين استخدام أداة مختلفة للتواصل مع بعضهم البعض عندما يحتاجون إلى القيام بذلك على انفراد (مثل الرسائل الخاصة أو فئة خاصة بالموظفين أو قناة دردشة). إذا كان ذلك مقبولًا، يمكنك القيام بذلك اليوم.
للأسف، نحتاج أيضًا إلى إدارة المستخدمين الداخليين لدينا في بعض الأحيان! عندما تبدأ في أن تصبح كبيرًا جدًا، تنشأ سيناريوهات مناسبة بنفس القدر لمناقشة المسؤول فقط. يمكنني أن أخبرك المزيد عن حالة الاستخدام هذه في رسالة خاصة، إذا كنت مهتمًا.
نعم!
على سبيل المثال، سيرى الموظفون هذا:
وسيرى الموظفون هذا:
هذه مجرد لقطات شاشة مركبة، لكن أعتقد أنها تعطي الفكرة.
نعم، أعتقد أن هذا يعطي الفكرة العامة.
ما زلت أشك في المفاضلة بين القيمة والتعقيد هنا، لكنني أفهم الآن كيف أن وجود نوع إضافي من الهمس سيحقق ما تطلبه الآن.
بالنظر إلى القيود الحالية للنظام، هل ستختار السماح للجميع بالهمس واستخدام حل آخر للمحادثات الخاصة بالمسؤولين فقط؟ أم ستختار إبقاء الهمسات مقصورة على المسؤولين فقط؟
من الصعب اتخاذ قرار في الوقت الحالي. الفلسفة التي أتبعها دائمًا مع فريقي هي القيام بما هو أفضل لمستخدمينا، وليس ما هو أسهل بالنسبة لنا، لأن ذلك سيكون في النهاية ما هو أفضل لنا أيضًا.
مع ذلك، أعتقد أنني سأترك الهمسات مفتوحة للجميع، وسيجعل فريقي محادثات الإشراف تنتقل إلى Slack أو ربما الدردشة عندما يتم إصلاح مشكلات الإشعارات. هذا ليس مثاليًا ويأخذ الهمس بعيدًا عن المشرفين/المسؤولين، ولكنه سيسمح لنا بمواصلة تنمية مجتمعنا.
+1 لهذه الميزة!
في حالتنا، لدينا فريق من المؤلفين والمساهمين غير المشرفين ونود أن نمنحهم خيار الهمس في فئات معينة دون جعل همسات الموظفين/المشرفين مرئية لهم.
لن يكون آمنًا. ويمكن للمستخدمين الماكرين التحايل عليه.
ولكن ماذا عن مكون سمة يستخدم CSS لإظهار “لا شيء” على همسة أنشأها الموظفون إذا لم يكن المستخدم الحالي موظفًا؟ بالنسبة لفئات معينة.
يمكن استخدام منطق مماثل لتبديل الهمسة في قائمة التروس لعدم عرض زر الهمسة لهذه المجموعة إذا لم تكن الفئات التي تريد السماح لهم باستخدام الهمسات.
ستحتاج مجموعة الموظفين إلى معرفة عدم مشاركة الأشياء ذات الحاجة الحساسة / الأمنية الحقيقية.
يمكن استخدام شيء مثل هذا كحل بديل مؤقت مع تحفظات.
هممم… كيف ذلك؟
طالما تم تنفيذ هذا في الواجهة الخلفية، فإن المشاركات التي يتم بثها إلى العميل ستعتمد على تفويض المستخدم المحدد.
لن يتم تضمين “همسات غير المسؤولين” في المعلومات المتسلسلة لأولئك غير المطلعين عليها.
إذا كانت هناك أي عوائق أمام تنفيذ ذلك، فلا أعتقد أن هذا هو أحدها.
كنت أعتمد فقط على CSS بسيط في مكون سمة.
ألن يحتاج ذلك إلى إضافة؟ أعتذر إذا كان منطقي الضبابي خاطئًا.
ومع ذلك، لديك فهم أفضل بكثير لهذه الأمور مني. ولكن يبدو رائعًا إذا كان قابلاً للتنفيذ كما قيل في وقت سابق في هذا الموضوع أنه لن يكون من الممكن إنشاء همسات منفصلة في هذا الوقت بسبب التعقيد.
كنت أستند إلى استنتاجي على الفكرة في موضوع آخر لاستخدام bbcode CSS عام لإظهار المحتوى المخفي فقط في منشور لمستخدم أو مجموعة معينة.
