تفضيلات البريد الإلكتروني لا تزال تظهر عند تعطيل رسائل البريد الإلكتروني

هناك بعض الأمور الغريبة التي تحدث من منظور تجربة المستخدم (UX) عندما يتم تعطيل جميع رسائل البريد الإلكتروني. أعتبر هذه أخطاءً.

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

من: https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/components/global-notice.js#L99

   if (
        this.siteSettings.disable_emails === "yes" ||
        this.siteSettings.disable_emails === "non-staff"
      ) {
        notices.push(
          Notice.create({
            text: I18n.t("emails_are_disabled"), // "All outgoing email has been globally disabled by an administrator. No email notifications of any kind will be sent."
            id: "alert-emails-disabled",
          })
        );
      }

أعتقد أنه يجب تعديل الشرط ليصبح:

if (
        this.get("currentUser.staff") && // أو currentUser.admin
        (this.siteSettings.disable_emails === "yes" ||
        this.siteSettings.disable_emails === "non-staff") 
      ) {
          …

أو على الأقل إضافة إعداد لتحديد من يتلقى هذا الإشعار (مثل: الجميع/الموظفين/المدراء/لا أحد).

أيضًا، في هذا الإصلاح: https://github.com/discourse/discourse/commit/acc121fd27e53fb70c888b58939027fbefba9c6f، يبدو أن الفكرة كانت أن إشعار تعطيل البريد الإلكتروني يجب أن يظهر فقط للموظفين، لكن الاختبارات https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/tests/acceptance/email-notice-test.js#L24 تؤكد أن الجميع يرى الإشعار.

ملاحظة ثانوية: أجد أن جميع الاختبارات بصيغة test("when … مربكة بعض الشيء. على سبيل المثال: الاختبار المسمى “When enabled” يفحص فعليًا قيمة disable_emails = "yes"، وهو ما، رغم أنني أفهم أن الاختبارات تهدف إلى فحص تغيير الإعدادات، إلا أنه في الواقع يفحص حالة تعطيل البريد الإلكتروني، والعكس صحيح حيث يفحص الاختبار المسمى “When disabled” حالة تفعيل البريد الإلكتروني. أعتقد أن التسميات تشير إلى القيم المحددة أكثر من التأثير النهائي، وهو ما قد يكون العرف المتبع في المشروع. وفي هذه الحالة، لا بأس بذلك. لكن يبدو غريبًا من منظور شخص جديد.

  1. سواء تم تعيين disable_emails إلى “yes” أو “non-staff”، فإن قسم البريد الإلكتروني لا يزال يظهر في صفحة تفضيلات المستخدم للجميع. وهذا غريب لأن القالب يحتوي على فحوصات لتعطيل أجزاء منه عند تعطيل الملخصات أو القوائم البريدية.

كما ترون، لا يوجد فحص هنا: https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/templates/preferences.hbs#L18

    <li class="nav-emails">
      {{#link-to "preferences.emails"}}
        {{i18n "user.preferences_nav.emails"}}
      {{/link-to}}
    </li>

في نسختي، لدي شيء من هذا القبيل: (لا أعرف إذا كان هذا هو الأسلوب الذي تتبعونه، بالمناسبة) أنا منفتح على الاقتراحات :wink:

      {{#if (show-emails-preferences model siteSettings.disable_emails)}}
          <li class="nav-emails">
            {{#link-to "preferences.emails"}}
              {{i18n "user.preferences_nav.emails"}}
            {{/link-to}}
          </li>
      {{/if}}

حيث يتم تعريف show-emails-preferences في دالة مساعدة (helper) على النحو التالي:

registerUnbound("show-emails-preferences", (model, disable_emails, args) => {
  let result = true;
  if(disable_emails === 'yes'){
    result = false;
  }else if(disable_emails === 'non-staff'){
    result = model.staff ? true : false;
  }else{
    result = true;
  }
    return result;
});

أخبرني إذا كان أي من هذه الاقتراحات يبدو تحسينًا يستحق العمل عليه، وسأقوم بإنشاء طلب دمج (PR).

تحياتي

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

لقد نسيت أن أذكر أنني أيضًا أقوم بتغليف القالب بالكامل
https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/templates/preferences/emails.hbs#L1
بـ

  {{#if (show-emails-preferences model siteSettings.disable_emails)}}
    {{#unless siteSettings.disable_mailing_list_mode}}
…

لا يمكن أن يعمل Discourse بدون البريد الإلكتروني.

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

إنه ليس خللاً أن لا يمكنك تعطيل هذا التحذير. إنه ميزة.

ماذا عن حالة استخدام SSO فقط للمصادقة؟
إحدى ميزات Discourse هي منع تسجيل الدخول عبر البريد الإلكتروني والسماح بـ SSO كنظام مصادقة وحيد.
يمكنك ضبط كل من “تفعيل تسجيل الدخول المحلي” و “تفعيل تسجيل الدخول المحلي عبر البريد الإلكتروني” على false.
كذلك ضبط “تعطيل البريد الإلكتروني” على “نعم”.
ربما لا يعمل كمنتج مستقل بذاته، لكنه يمكن أن يعمل كجزء من نظام أكبر. علاوة على ذلك، إذا كان ذلك صحيحًا، ولماذا كان “Discourse لا يعمل بدون بريد إلكتروني”، فلماذا توجد كل هذه الإعدادات التي قد تعطل النظام؟

“تظهر تلك اللافتة لأنها تخبر الجميع بأن الموقع معطل.”
مرة أخرى، لا أعتقد أن “الجميع” بحاجة إلى معرفة ذلك.
على الأقل في رأيي، فقط الموظفون أو المسؤولون هم من يحتاجون إلى المعرفة، وليس مستهلكو المنتج.

بالمناسبة، هذا هو كيفية استخدامنا له. لدينا موقع ويب رئيسي تقوم من خلاله بتسجيل الدخول/تسجيل الخروج/التسجيل/إعادة تعيين كلمة المرور، وما إلى ذلك.
الطريقة الوحيدة للوصول إلى Discourse هي عبر SSO. بهذه الطريقة يمكننا بسهولة توفير الأذونات عبر المجموعات.

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

@pfaffman، على جانب آخر، ما رأيك في تلك الطريقة؟

هل هذا هو المستوى أو الأسلوب الصحيح (من منظور أسلوب discourse) للقيام بذلك؟

لم أتمكن من تخصيص وقت كافٍ لاستكشاف الكود بشكل عميق أو استخلاص “أسلوب discourse” صارم لكتابة الأكواد.

نعم، قد تكون على حق. لقد واجهت للتو مثيل Discourse يعمل في الواقع مع تمكين SSO، لكنه يعرض أيضًا شريط “تم تعطيل البريد الإلكتروني” بينما لم أقم بتسجيل الدخول بعد.

مع SSO، لن يضطروا للقلق بشأن إعادة تعيين كلمات المرور، لذا وبالإضافة إلى إشعارات البريد الإلكتروني التي لن يتلقاها المستخدمون، لست متأكدًا من سبب وجوب عرض هذا الشريط للجميع إذا كان SSO مفعّلًا.

ربما يمكننا على الأقل تحديثه لعدم إظهار الشريط إذا كان SSO مفعّلًا ولم تكن مسجّل الدخول؟

إعجابَين (2)

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

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