لقد قمت مؤخرًا ببناء تكامل مذهل لمجتمعي، ولكنه يفتقر إلى ميزة واحدة حاسمة: أريد إخطار المستخدمين المشتركين في موضوع ما عند تحديث المنشور الأصلي. إليك السيناريو الخاص بي:
لدينا منصة SaaS، ومثل العديد، لدينا صفحة حالة: status.sailpoint.com حيث يمكن لمستخدمينا مراقبة الحوادث والاشتراك فيها عند حدوثها على منصتنا. المشكلة في هذه الحوادث هي أنها أحادية الاتجاه للغاية، لذا لا يمكن لعملائنا التواصل معنا أو مع بعضهم البعض حول كيفية تأثير هذا الحادث عليهم. ما يحدث هو أنهم ينتهي بهم الأمر بإغراق مديري نجاح العملاء (CSMs) وخطوط الدعم لدينا للسؤال عما يحدث (وهو أمر مفهوم).
لتخفيف ذلك، خطرت لي فكرة دمج Discourse في التجربة. عندما يحدث حادث جديد، ستحتوي صفحة الحادث على status.sailpoint.com على رابط/رسالة لطيفة مثل “انقر هنا لمناقشة هذا الحادث”. في الواجهة الخلفية، نقوم بإجراء استدعاءات API لإنشاء وتحديث موضوع في Discourse مع تقدم الحادث، على النحو التالي:
هذا رائع لأن عملائنا لديهم الآن منفذ للمحادثة في مكان واحد، ولدى مديري نجاح العملاء/الدعم نقطة التقاء عامة واحدة للاستجابة وتخفيف المخاوف.
المشكلة
في كل مرة نضيف فيها حادثًا جديدًا إلى هذا المنشور الأصلي، أريد إخطار المشتركين في الموضوع. لا أريد إنشاء منشورات جديدة في الموضوع للقيام بذلك، أريد أن يكون كل شيء في المنشور الأصلي. لا أريد أيضًا منشورات جديدة في الموضوع يتم ربطها بعد ذلك برابط واحد في المنشور الأصلي.
يتم إعلامي عندما يقوم الفريق هنا بتعديل مواضيع التوثيق التي أراقبها. ربما لأن المنشورات الأصلية هي منشورات ويكي. إذا كان الأمر كذلك، فربما يكون هذا هو حلك. ستحتاج إلى تعيين مستوى الثقة المسموح به لتعديل منشورات الويكي (min trust to edit wiki post) إلى ما تحتاجه.
سيكون ذلك قريبًا جدًا! لكن لا يمكنني السماح لغير الموظفين بتعديل هذه المنشورات بسبب حساسيتها، لكنني ما زلت أرغب في أن تتمكن مجموعة مستوى الثقة المختارة من تعديل الويكي في المنشورات الأخرى.
لا أعرف الإجابة على هذا، ولكن ماذا عن تغيير إعدادات الفئة بحيث يمكن للمستخدمين العاديين الرد ولكن ليس الإنشاء - هل لهذا تأثير في منع المستخدمين العاديين من تعديل منشور الويكي الأصلي؟
ما لم يكن لديك عملاء يقومون بتحرير منشورات الويكي في مكان آخر على تثبيت Discourse الخاص بك، يمكنك ببساطة رفع الحد الأدنى للثقة لتحرير منشور الويكي إلى TL3 (إذا جعلته غير متاح) أو TL4 وتأكد من أن موظفيك على نفس المستوى أو أعلى.
أوه لا، لم أكن على علم بأن المستوى 4 (TL4) يمكنه تعديل جميع المشاركات. ومع ذلك، هناك حل بسيط، سنمنح المستوى 4 (TL4) لسفرائنا في برنامج السفراء الخاص بنا، وهو برنامج لدينا لأفضل المساهمين لدينا. يتم التعامل مع ذلك بواسطة مستوى الثقة في مجموعة المستخدمين، لذا سأقوم بخفضه إلى المستوى 3 (TL3).
هذه المحادثة تحفزني على إعادة النظر في مستويات الثقة
ما زلت بحاجة إلى إيجاد حل لهذا على الرغم من ذلك! قد أحتاج إلى إشراك فريق الخدمات لهذا الأمر.
أرى أن المواضيع في Plugin هي عبارة عن موسوعات، لذا يجب أن تكون هذه هي الطريقة التي يفعلون بها ذلك هنا في Discourse. حسنًا، سأقوم بتثقيف نفسي بشكل أفضل حول مستويات الثقة أولاً للتأكد من أنني أفهمها بشكل صحيح أولاً.
سأقول مع ذلك، أنا لا أحب فكرة جعلهم مشرفي فئات. ألا يعني ذلك أنهم سيظهرون كمشرفي مجتمع في /about؟
سيظهرون في قسم أسفل المشرفين والمراقبين، مع اسم الفئة الذي يشير إليهم كمراقبين لتلك الفئة.
يمكنك استخدام CSS لإخفاء هذا.
ربما انتظر لترى ما إذا كان أي شخص آخر يقدم حلاً أكثر قبولاً إذا كان هذا يبدو تغييرًا كبيرًا جدًا.
ومع ذلك، فإن التعرف على مستويات الثقة أمر جيد دائمًا، سأبدأ هنا ثم ربما ألقي نظرة على جدول الأذونات.
سأفعل ذلك بالضبط. أشعر أنه في حالة الاستخدام الخاصة بمؤسستنا، لن نرغب في أن تسرد مجتمعنا المستخدمين العاديين (العملاء/الشركاء) كمسؤولين، لأن ذلك قريب جدًا من أن يبدو وكأنهم مرتبطون رسميًا بعمليات أعمالنا في أي قدرة.
