The Discourse Staff Alias plugin allows certain groups to create topics and posts, as well as make edits, as an alias user. This can be useful in situations where staff members need to respond to queries or make announcements without revealing their personal usernames.
Enabling Staff Alias
Once installed, the Staff Alias plugin can be enabled from its settings, accessed from your admin/plugins page:
Once the plugin is enabled, a user with that username will be created.
Using the Alias
Once enabled, the staff alias can be toggled on using the composer’s actions drop-down, and users in the allowed groups can then choose to create topics and posts, as well as make edits, using the staff alias:
هناك احتمال أن أكون قد ارتكبت خطأ عند كتابة التعليمات.
لا يمكنني أيضًا جعل مستخدم موجود اسمًا مستعارًا للموظفين الآن بعد أن اختبرته مرة أخرى، وهو أمر منطقي عندما أفكر في الأمر. لست متأكدًا مما جعلني أعتقد أنه كان ممكنًا. سأقوم بتحديث التعليمات.
شكرا لك! من المؤسف لأنني أعتقد أنه يوحد الأمور عندما يمكن لجميع أعضاء الفريق استخدام اسم الموقع أو حساب “رئيسي” موجود بالفعل. على سبيل المثال @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 لا يمنع الحسابات المميزة مثل المسؤولين والمشرفين من مراسلته – وهذه الرسائل لا تُرى إلا إذا تم البحث عنها. ربما يمكن توجيه هذه الرسائل أيضًا إلى الحساب “الأصلي” ذي الصلة؟
هذه الأمور ليست مصدر قلق كبير بالنسبة لي حتى الآن، ولكني أستطيع تخيل مشاكل للمواقع التي بها المزيد من الموظفين والنشاط المكثف. سأراقب أي أخبار… شكرًا!
سأقوم بتحديث التعليمات. 
