تسمح إضافة Discourse Staff Alias لمجموعات معينة بإنشاء مواضيع ورسائل، وإجراء تعديلات، باسم مستخدم بديل. يمكن أن يكون هذا مفيدًا في الحالات التي يحتاج فيها أعضاء الطاقم إلى الرد على الاستفسارات أو إصدار الإعلانات دون الكشف عن أسماء مستخدماتهم الشخصية.
تمكين Staff Alias
بعد التثبيت، يمكن تمكين إضافة Staff Alias من إعداداتها، والتي يمكن الوصول إليها من صفحة admin/plugins الخاصة بك:
بمجرد تمكين الإضافة، سيتم إنشاء مستخدم يحمل ذلك الاسم.
استخدام البدائل
بمجرد التمكين، يمكن التبديل إلى استخدام البدائل من خلال قائمة الإجراءات المنسدلة في المصمم، ويمكن للمستخدمين المنتمين إلى المجموعات المسموح بها اختيار إنشاء مواضيع ورسائل، وإجراء تعديلات، باستخدام بديل الطاقم:
هناك احتمال أن أكون قد ارتكبت خطأ عند كتابة التعليمات.
لا يمكنني أيضًا جعل مستخدم موجود اسمًا مستعارًا للموظفين الآن بعد أن اختبرته مرة أخرى، وهو أمر منطقي عندما أفكر في الأمر. لست متأكدًا مما جعلني أعتقد أنه كان ممكنًا. سأقوم بتحديث التعليمات.
شكرا لك! من المؤسف لأنني أعتقد أنه يوحد الأمور عندما يمكن لجميع أعضاء الفريق استخدام اسم الموقع أو حساب “رئيسي” موجود بالفعل. على سبيل المثال @Discourse
لا يمكن الرد على إعادة إرسال الرسالة للمستخدم باستخدام اسم مستعار للموظف، حيث أتلقى الخطأ المذكور أعلاه، ولكن إذا استخدمت اسم مستعار للموظف للرد على موضوع الرسالة، فسيكون الأمر مقبولاً.
ما هي احتمالات توسيع هذا ليصبح أداة ديناميكية “لنشر باسم مستخدم آخر”؟
لدينا حالة استخدام حيث لدينا مدير اتصالات منتجات يحتاج إلى إنشاء مواضيع جديدة باسم مديري منتجات آخرين في مؤسستنا. تبدو هذه الأداة وكأن معظم الوظائف موجودة، ولكنها ستتطلب القدرة على تعيين المستخدم الذي يتم النشر باسمه ديناميكيًا.
أردت أن أشير إلى أنني قضيت بضع دقائق في محاولة معرفة سبب إنشاء مشرف غامض على موقع ما.
كان لهذا المستخدم بريد إلكتروني عشوائي التجزئة، وبدا مشبوهًا إلى حد ما.
أعتقد أنه سيكون من الجيد ترك ملاحظة للموظفين، أو تسجيل “منح الإشراف” في سجل الموظفين، أو تقديم أي مؤشر آخر على أن هذا المستخدم تم إنشاؤه بواسطة مكون إضافي
أنا أجرب هذا، وأتساءل: ما هو السلوك المتوقع فيما يتعلق بالإشعارات ورسائل البريد الإلكتروني للمستخدم staff_alias؟
يحصل المستخدم staff_alias على سلسلة عشوائية بدلاً من عنوان بريد إلكتروني - لذلك يتم تخطي رسائل البريد الإلكتروني التي يتم إرسالها عادةً.
لا يمكنني منح الاسم المستعار للموظفين عنوان بريد إلكتروني حقيقي، حيث يحاول Discourse إرسال بريد إلكتروني للتأكيد إلى السلسلة العشوائية.
هل staff_alias طريق ذو اتجاه واحد؟ ربما فاتني شيء ما. هل هناك - أو يجب أن يكون هناك - طريقة لجعله يعمل كـ “واجهة” لحساب حقيقي، مثل المسؤول، يتلقى الاتصالات كالمعتاد؟
في إدارة المجتمعات الكبيرة، يمكن أن تكون الهوية صعبة للغاية. عندما تسمح للعديد من “الموظفين” بالنشر بصفتهم “staff alias”، يتم عرض حساب المشرف الفعلي الذي استخدم staff alias للنشر للموظفين أيضًا كما هو موضح في لقطة الشاشة
إذا وضعت “حسابًا حقيقيًا” خلف staff alias، فهناك العديد من خيارات المستخدم الأخرى التي يتم كشفها مما يجعل من الصعب التحقق من الموظف الذي قام بتغييرات معينة للحساب.
ما نوع “التواصل” الذي تتوقع تلقيه؟ أشعر أن هناك طريقة أخرى للوصول إلى ما تأمل في تحقيقه.
شكراً على الرد، @nat. لقد افترضت ببساطة أنه إذا قمت بالنشر باستخدام staff_alias، فقد يستجيب المستخدمون، ولن أرغب في تجاهلهم.
كنت أخشى ألا يرى أحد مثل هذه الإشعارات – ولكنني اكتشفت منذ ذلك الحين أنني أتلقى هذه رسائل البريد الإلكتروني والإشعارات على حساب الموظفين الذي استخدم الاسم المستعار. لذا، هذا رائع.
زوج من الأسئلة المتبقية:
سجل البريد الإلكتروني الذي تم تخطيه يتضمن حالات فشل في محاولة الإرسال إلى السلسلة الوهمية staff_alias. هل يمكنني تخمين أنني أستطيع إيقاف تشغيل جميع إعدادات البريد الإلكتروني لـ staff_alias، وسيتم تشغيل رسائل البريد الإلكتروني وإرسالها إلى حساب الموظفين “الأصلي”؟
لا يمكنني رؤية الرسائل الشخصية إلى staff_alias إلا عن طريق البحث في ملفه الشخصي عبر المسؤول. ربما يكون من المنطقي تعطيل المراسلة الشخصية لـ staff_alias؟
شكراً على أي نصيحة هناك.
أشعر أنني أقرب إلى فهم الأمور بعد المزيد من التجريب… ولكن موضوع المكون الإضافي يمكن أن يستفيد من ذكر كيفية توجيه الإشعارات، وبعض الإرشادات حول إعدادات الحساب الأخرى ذات الصلة.
مرحباً @nat – يبدو أن المكون الإضافي يحتاج إلى بعض الضبط الدقيق:
أ.) لقد حاولت إيقاف تشغيل البريد الإلكتروني لـ staff_alias، وأصبح الأمر أشبه بالثقب الأسود. لا يتم تشغيل رسائل البريد الإلكتروني والإشعارات إلى الحساب “الأصلي”. لذلك سأعيد تمكين البريد الإلكتروني وأتجاهل إشعارات البريد الإلكتروني التي تم تخطيها في الوقت الحالي.
ب.) تعطيل المراسلة الشخصية لـ staff_alias لا يمنع الحسابات المميزة مثل المسؤولين والمشرفين من مراسلته – وهذه الرسائل لا تُرى إلا إذا تم البحث عنها. ربما يمكن توجيه هذه الرسائل أيضًا إلى الحساب “الأصلي” ذي الصلة؟
هذه الأمور ليست مصدر قلق كبير بالنسبة لي حتى الآن، ولكني أستطيع تخيل مشاكل للمواقع التي بها المزيد من الموظفين والنشاط المكثف. سأراقب أي أخبار… شكرًا!
مستضاف لدينا؟ هذه الإضافة متاحة في مستوى Enterprise الخاص بنا.
سأقوم بتحديث التعليمات. 
