ملاحظات حول كتم أو حذف المستخدمين

الغرض من هذه الملاحظة هو تلخيص تجربة المستخدم الإدارية الخاصة بي أثناء إسكات بعض المستخدمين. لا أطلب تغييرات بالضرورة، بل أذكر التحديات التي قد تترجم إلى طلبات عند المراجعة.

  1. عندما أحتاج إلى إسكات مستخدم بسبب رفض رسائل البريد الإلكتروني، لا أريد إرسال بريد إلكتروني لإعلامهم بالحدث. :slight_smile:
  2. لا أرى خيارًا إداريًا لإضافة سبب مخصص للإسكات إلى القائمة الحالية. أود إضافة “رفض رسائل البريد الإلكتروني”.
  3. أود تعيين أحد خيارات فترة الإسكات المتاحة ليكون الافتراضي. لا أريد الاضطرار إلى تعيين الفترة الزمنية من القائمة المنسدلة لكل حدث.
  4. أريد نصح المستخدم بشأن سبب إسكاته، بمعلومات أكثر من السطر الواحد “السبب”. الصندوق موجود لإرسال بريد إلكتروني للمستخدم مع ملاحظة، ولكن مرة أخرى، هذا يرسل بريدًا إلكترونيًا للمستخدم. أريد فقط مراسلته لأنني أعرف أن البريد الإلكتروني لا يعمل.
  5. هل يتم إرسال رسائل بريد إلكتروني أخرى من Discourse إلى المستخدم بعد حظره أو إسكاته؟ لهذا السيناريو المحدد وربما سيناريوهات أخرى، لا أريد إرسال أي بريد إلكتروني إضافي لهذا المستخدم، خاصة إذا كان مشتركًا في العديد من الإشعارات.
  6. حول حذف مستخدم في نفس السيناريو: يمكننا ببساطة حذف المستخدم، ويمكننا أيضًا “حذف وحظر كل من عنوان البريد الإلكتروني وعنوان IP”. لماذا ترتبط هذه؟ أحب فكرة حظر عنوان بريد إلكتروني. قد أرغب نادرًا في حظر عنوان IP. لكن حظر IPv4 محرج لعدد من الأسباب - ربما يكون جيدًا مع IPv6 ولكننا لسنا هناك بعد. حتى يتم فصل هذه المفاهيم، ألا يمكننا ببساطة حظر عنوان بريد إلكتروني؟ إذا كنت أعرف المزيد عن التفاصيل الداخلية لـ Discourse، فسأكون سعيدًا بإنشاء عملية تمسح عناصر معينة من قوائم الحظر، لكنني لا أعرف مكان العثور على تلك البيانات.
  7. لدينا MaxMind نشط لهذا الموقع وأود استخدام عنوان IP للحصول على موقع للمساعدة في تحديد ما إذا كان يجب إسكات المستخدم أو حذفه. على سبيل المثال، إذا كان آخر عنوان IP مستخدم بعيدًا عن عنوان التسجيل (بالإضافة إلى المقاييس الأخرى) فسأقوم بحذف الحساب لأنه “سيء الرائحة”. لكن النافذة المنبثقة التي تعرض معلومات IP لا تعرض موقعًا. هل هذا خطأ أم يجب علي التحقق من MaxMind مرة أخرى؟
  8. أتلقى إشعارات بالرفض على عنوان postmaster@ الخاص بي - هذه هي الطريقة التي أعرف بها أن البريد الإلكتروني من المنتدى يرتد. قد يقترح البعض علي النظر في درجة الارتداد للحصول على قطع تلقائي لتجنب إرسال بريد إلكتروني لشخص لديه بالفعل مرتجعات مسجلة. ليس لدينا بيانات ارتداد للتسجيل، لم أقم بإعداد Discourse لاستطلاع POP3 (IMAP؟) لمثل هذه البيانات. كل ما أراه في meta هي حكايات المنتدى حول إعداده. هل هناك وثيقة مخصصة حقيقية حول هذا الموضوع؟

مرة أخرى، كل هذا فقط لمشاركة تجربة المستخدم (غير الرائعة) في هذا المجال المحدد، لمن قد يكون مهتمًا.

آمل أن يكون هذا مفيدًا - وشكرًا!!!

إعجابَين (2)

أفترض أنه إذا تركت سبب الإسكات فارغًا، فلن يتم إرسال بريد إلكتروني إليهم.

بالنسبة لذلك، راجع Custom Predefined Suspension Reasons

  • هذا يعتمد على ما أعرفه عن Discourse (لن يكون دقيقًا، لكنني أحاول المساعدة!)
إعجاب واحد (1)

2468 - نحن نقدر! :slight_smile:

إعجابَين (2)

كيف قمت بتكوين إعدادات الموقع bounce score خاصةً bounce score threshold؟

إعجابَين (2)

لم أقم بتهيئة حد درجة الارتداد بعد لأنني لا أملك Discourse للتحقق من البريد الإلكتروني لإشعارات الارتداد. المعلومات الموجودة في هذا الموضوع في meta هي أفضل ما وجدته حول موضوع تهيئة معالجة الارتدادات. خلال الأيام القليلة القادمة، سأبحث عن وثائق أكثر اكتمالاً.

لكن نعم، اليوم سأضع حدًا منخفضًا جدًا للارتداد.

إعجاب واحد (1)

لا، هذا غير صحيح.

يجب اختيار سبب أو كتابته قبل أن يصبح من الممكن إسكات الحساب.

{“translation”: "[quote=“Architect, post:6, topic:323151”] يجب أن يكون هناك سبب مختار أو مكتوب قبل أن يكون من الممكن إسكات الحساب.[/quote]
هذا منطقي لأنه يتم إرسال رسالة موقع إلى المستخدم لإبلاغه بالحدث. تلك الرسالة غير واضحة بشأن ما نريد بالضبط من المستخدم أن يفعله. لذلك بعد إرسال الرسالة، أرسل ردًا على تلك الرسالة للمستخدم، لأطلب منه الرد عندما يصحح وضع البريد الإلكتروني.

لذا التحديات التي أواجهها الآن تشمل:

  • أريد تلك الرسالة للمستخدم، لكنني أفضّل تعديل النص. تغيير admin/customize/email_templates/system_messages.email_revoked للإنجليزية لا يغيرها لجميع اللغات الأخرى. أم يوجد ميزة لتشغيل ترجمة تلقائية على واحدة أو جميع رسائل النظام؟
  • بدون بحث على admin/customize/email_templates/ من الصعب العثور على النص الصحيح للرسائل النظامية أو إشعارات المستخدم للتحرير، ومعرفة العمليات التي ت triggersها.
  • لا أريد إرسال بريد إلكتروني عندما يكون المشكلة من التعريف أن المستخدمين لا يتلقون البريد.
  • عندما أنشر ذلك الرد على رسالة النظام في ملف تعريف المستخدم لديهم، يُرسل بريد إلكتروني آخر. إذا استطعنا حظر البريد الصادر عن العنوان الذي لن يحدث ذلك. هل جميع وظائف البريد الصادر تمر عبر عملية مركزية تفحص أولاً إذا تم تجاوز عتبة الارتداد؟ أم أنني أفتقد ميزة حول الصمت (Silence) التي تحظر البريد الصادر دون الحاجة إلى ربط ذلك بعتبة الارتداد؟
  • من المثالي عندما يستبدل المستخدم عنوان البريد الإلكتروني بشيء صحيح، أو ينقر على “عنواني الآن على ما يرام”، يكون من الرائع أن يرسل الخادم بريد اختبار وعند النجاح يحذف علامة/عدد الارتداد.
  • (عشوائيًا) هناك عدد ثابت من أسباب تعليق المستخدمين في admin_js.admin.user.suspend_reasons ويتم تحديدها بشكل “صارم” لمنع التخصيص لغرض آخر. بمعنى، يمكننا تغيير النص لـ admin_js.admin.user.suspend_reasons.combative وهناك admin_js.admin.user.suspend_reasons.custom لكن لا يبدو أنه يمكننا إنشاء واحد جديد admin_js.admin.user.suspend_reasons.bouncing_email.

هذه السيناريوهات لا تنطبق فقط على الارتدادات. يمكنني التفكير في سيناريوهات أخرى نرغب فيها في إشعار المستخدم برسالة محلية لا يمكننا إرسال بريد لهم ونقدم لهم رسالة مخصصة تخبرهم بما ينبغي عليهم فعله.

أعتقد أن كل هذا يصف سلوكًا دقيقًا جدًا ربما لا يتدفق بسهولة ضمن قائمة الأولويات، لكنني لست متأكدًا بعد إن كان أو كيف يتعامل الآخرون مع هذا. شكرًا لصبركم…"}

جارٍ تحديث هذا الموضوع بالتقدم المحرز…

لقد وجدت هذه الوثائق لإعداد معالجة الارتداد:

الصور هنا مفيدة للغاية أيضًا:

يجب أن يعالج تنفيذ هذه الوظيفة ما يكفي من التحديات هنا للتعامل مع البريد المرتد بفعالية. ما زلت بحاجة إلى معرفة كيفية إخطار قاعدة مستخدمين متعددة اللغات بفعالية وإعادتهم إلى المسار الصحيح بسرعة عندما يقومون بإصلاح مشاكل البريد الإلكتروني. أي، عندما يقومون بإجراء تغيير فعال يحتاجون إلى إخطارنا أو النظام حتى يمكن رفع الحظر المفروض عليهم.

عندما يكون عنوان البريد الإلكتروني يرتد مرة أخرى رسائل البريد الإلكتروني الآلية من discourse، يبدو أنك لن تحتاج بالضرورة إلى إسكات حسابهم أو حذفه لهذا السبب ما لم تشك في أنه حساب مزيف أو شيء بدون بريد إلكتروني صالح.

أعتقد أن هذا هو السبب على الأرجح الذي قد ترغب في تعليق الحساب مؤقتًا للتحقق من أن لديهم بريدًا إلكترونيًا يعمل، هل لديك حجم كبير من الحالات مثل هذه أم أنه من العملي التعامل معها واحدًا تلو الآخر يدويًا؟

هناك بعض الخيارات الأخرى مثل تغيير إعدادات إشعارات البريد الإلكتروني يدويًا، أو تغيير عنوان البريد الإلكتروني الذي لا يعمل إلى عنوان آخر يعمل يتحكم فيه المسؤول أو شيء من هذا القبيل مؤقتًا. قد لا تكون هذه أفضل فكرة، مجرد بعض الأفكار العشوائية هنا.

عند حذف حساب، لا يتم إرسال إشعار بريد إلكتروني بذلك في آخر مرة تحققت فيها. سياسة بسيطة ولكنها قاسية نوعًا ما هي حذف الحسابات إذا لم يكن لديها بريد إلكتروني يعمل.

نحن على نفس الصفحة. هناك سيناريوهات مختلفة يرغب المديرون المختلفون في التعامل معها بشكل مختلف. أنا أستكشف هذا البرنامج لفهم ما يفعله، وكيف يُقصد استخدامه، وكيف يستخدمه الآخرون.

الهدف الأساسي لهذه المبادرة/التحقيق ذو شقين: أولاً، تجنب الإساءة بشكل استباقي. ثانيًا، تجنب إرسال رسائل بريد إلكتروني سترتد، مما قد يؤدي إلى تصنيف موقعنا كمصدر للبريد الإلكتروني غير القابل للتسليم. يمكن أن يؤدي هذا إلى إدراجات مؤقتة في قوائم الحظر (RBLs) وأنا أرغب في تجنب مثل هذه التفاهات.

ليس لدينا حجم كبير لهذا الموقع، ولكن هناك مجموعات مستخدمين، مشابهة لمجموعات TL0-4 ولكنها مختلفة. لا ينبغي إسكات المستخدمين في مجموعة واحدة إذا حدث خطأ ما في بريدهم الإلكتروني. لا ينبغي إسكات المستخدمين في مجموعة أخرى لديهم بعض المشاركات الأخيرة ذات الصلة بالموضوع. قد يتم إسكات الحسابات التي لا تحتوي على نشاط أو لا تحتوي على نشاط صالح حديث للحصول على انتباههم إذا عادوا مرة أخرى.

مفهوم إسكات الأشخاص للحصول على انتباههم محرج. وأنا لا أهتم حقًا بعناوين البريد الإلكتروني. القصد الحقيقي هناك هو أنه إذا كان لدينا عنوان بريد إلكتروني وهمي، فأعتقد أن الحساب من المرجح أن يكون مصدرًا للإساءة. لذلك سأقوم بإسكاتهم بشكل استباقي، وأطلب بعض الاستجابة، وإذا لم نسمع منهم لفترة طويلة، فسأقوم بحذف الحساب. قد يتم وضع مستخدم مشارك (TL1؟) لم نسمع منه لفترة طويلة في وضع الصمت/المراجعة طويل الأمد.

نظرًا لأننا هنا، كل هذا يعني أيضًا أن الأشخاص ينشئون حسابات بدون بريد إلكتروني صالح، أو يغيرون عناوينهم إلى شيء غير صالح. أنا أراجع قسم Documentation وسأرغب في إنشاء أتمتة لـ: إسكات مستخدمي TL0 الجدد حتى بعد مشاهدتهم لبعض المواضيع، ثم إرسال بريد إلكتروني إليهم. إذا تلقينا ارتدادًا من هذه الرسائل المحددة، فسنضعهم في حالة مراجعة. لذلك لن يتم إرسال أي بريد ترحيبي حتى نتأكد من أنهم بشر يتفاعلون مع الموقع، ولن يتم منح أي أذونات حتى نتأكد من أنهم يتحققون من بريدهم الإلكتروني.

على أي حال، لا يمكن تفعيل حسابك دون التحقق من بريدك الإلكتروني أولاً (ما لم يتم تفعيله يدويًا بواسطة مسؤول، أو كنت تستخدم SSO ولا تتحقق باستخدام موفر الهوية الخاص بك).

3 إعجابات

هذا ليس صحيحًا بالضرورة، فهناك أسباب أخرى مثل قد يكون البريد الإلكتروني معطلاً مؤقتًا، أو قاموا بحظر المرسل الخاص بك (والذي قد يكون مؤقتًا أيضًا، كما في صمت الحساب المؤقت).

الخطوة الأولى التي أوصي بها لما تصفه هي إرسال رسالة خاصة عادية للمستخدم إذا لم يكن بريده الإلكتروني يتلقى رسائل كتنبيه بشأن ذلك في حال لم يكونوا على علم، يمكنك جعل ذلك رسالة تحذير رسمية مع مربع الاختيار لجعل أيقونة تنبيه الظرف حمراء بدلاً من خضراء. هذا يضع أيضًا ملاحظة على حسابهم بأنهم قد تم إرسال رسالة تحذير رسمية واحدة أو أكثر لهم حتى يكون لديك ذلك موثقًا.

كما ذكرنا مع الإعدادات الافتراضية، يجب التحقق من صحة الحسابات الجديدة عن طريق النقر على الرابط في البريد الإلكتروني للتحقق أولاً قبل أن يتمكنوا من استخدام موقعك، ما لم تكن قد تجاوزت ذلك.

يبدو أن هذا ممكّن بالفعل بشكل أساسي مع الإعدادات الافتراضية، على الرغم من أن TL0 يمكنه نشر ردود/مواضيع عامة إلا أنه لا يمكنه إرسال رسائل خاصة لأي شخص حتى يتم ترقيته إلى المستوى الأساسي TL1، والذي يتطلب بعض القراءة ويجب التحقق من صحة البريد الإلكتروني قبل ذلك.

إعجاب واحد (1)