رابط بريد التأكيد الإلكتروني (بعد التغيير) معطل («عذراً!») بسبب تخصيص البريد الإلكتروني السيء

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

https://forum.{mySite}.com/u/{user}/preferences/email

  1. يتلقى المستخدم رسالة تأكيد بنجاح.
  2. ينقر المستخدم على الرابط.
  3. يظهر خطأ: “عفوًا! الصفحة غير موجودة أو خاصة”.

image

قالب رابط رسالة التأكيد:

%{base_url}/u/authorize-email/%{email_token}

رابط رسالة التأكيد الفعلي:

https://forum.{mySite}.com/u/authorize-email/{someHash}

هل يمكنك تكرار هذا @tshenry؟

حدث هذا أيضًا لدينا هذا الأسبوع، تمامًا كما هو موضح أعلاه.

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

يرجى الانتقال إلى /admin/customize/email_templates/user_notifications.confirm_new_email والتأكد من أن الرابط بداخلها يبدو كالتالي:

%{base_url}/u/confirm-new-email/%{email_token}

بدلاً من:

%{base_url}/u/authorize-email/%{email_token}


قد يكون من الجيد إضافة هجرة (migration) في النهاية. لقد طُرح هذا الأمر عدة مرات بالفعل.
@sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4

تم التعامل مع الرابط المعطوب… إلى حد ما؛ الآن، يقوم فقط بإعادة توجيه المستخدم إلى شاشة تسجيل الدخول.

على الرغم من أنه جيد أن هذا الأمر قد لفت انتباهي لضمان قدرة المستخدمين على تغيير بريدهم الإلكتروني، فلماذا لا توجد طريقة للمسؤول لتعديل البريد الإلكتروني من لوحة التحكم؟ هل الطريقة الوحيدة هي انتحال الشخصية >> الملف الشخصي >> تغيير البريد الإلكتروني؟ هذا ما قرأته على أي حال - هل هذه حقًا الطريقة الصحيحة للقيام بذلك؟

يمكنني حذف حساب وانتحال الشخصية لكن لا يمكنني تغيير البريد الإلكتروني؟ يبدو هذا قليلًا غير بديهي~

%{base_url}/u/confirm-new-email/%{email_token}

رابطي يبدو هكذا ولا يزال يرسل الأشخاص إلى رسالة خطأ “أوبس”. هل تقصد أنه يجب أن يكون العكس؟

بالنسبة لي، يؤدي الرابط %{base_url}/u/confirm-new-email/%{email_token} إلى إعادة توجيه المستخدمين إلى صفحة تسجيل الدخول دون تفعيل الحساب. أما الرابط الآخر فهو صفحة “أوبس”.

هذا غريب، لكن:
كان الأمر هكذا:
%{base_url}/u/confirm-new-email/%{email_token} وأظهر رسالة خطأ

غيرته إلى هذا:
%{email_token}/u/authorize-email/%{base_url} وما زال يظهر رسالة خطأ

عدلتُه يدويًا إلى هذا:
%{base_url}/u/confirm-new-email/%{email_token} (وليس عن طريق إعادة تعيينه)
والآن يعمل! :woman_shrugging:

تعديل: أوه، والآن لا يعمل مرة أخرى.

أود تأجيل هذا الأمر لفترة أطول قليلاً.

ماذا عن رابط بديل متوافق مع الإصدارات السابقة (مُعلَّق)؟ أو سكريبت استبدال لعدة إصدارات؟ هل يمكن استخدام دالة replace() لاستبدال %{} القديمة بـ %{} الجديدة في الإصدار التالي؟ إذا كان الترحيل قد تم بالفعل، فلن يحدث شيء.

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

https://forum.{mySite}.com/u/confirm-new-email/{someHash}

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

أنا لا أفهم، لماذا لا تحذف ببساطة جميع تخصيصات اللغة ذات الصلة لديك وتبدأ من الصفر؟

لأنني مثل غيري — لا يدركون حتى أن هذا قد حدث. فليس الأمر كما لو أن زر “انقر للتحديث” كان مضيئًا ومزودًا بأضواء وامضة تخبرنا بتغيير قالب البريد الإلكتروني الخاص بنا.

لقد فعلت ذلك تمامًا، ولكن:

  1. لن تدرك أن هذا يحدث إلا إذا اكتشفت المشكلة عمدًا، ثم بحثت عنها في جوجل، ووجدت هذا المنشور، وقمت بحلها يدويًا.
  2. هذه العملية ليست بديهية على الإطلاق (بالإضافة إلى افتراض أن المستخدم سيعرف سحرًا أن هذا يحدث)، وهو أمر لا يتناسب مع طبيعة Discourse.
  3. فقدان الدقة وتعقيد المهمة — إذا أخطأت في القالب، ستحتاج إلى رسالة بريد إلكتروني تجريبية للاختبار. ولن تعرف حتى إلى ماذا يجب تغييره دون العثور على هذا المنشور.

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

من يدري كم من الوقت استمر هذا الأمر على منتداك؟ أتساءل كم من المستخدمين الجدد فقدنا لأننا لم نكن نعلم أن التحديث x تضمن تغييرًا مكسّرًا في القالب؟ لا يمكن أن أكون الشخص الوحيد الذي واجه هذا.

فقط أردت أن أتابع هذا الأمر

لم قمت بتخصيصه مطلقًا. إنه يحتوي على %{base_url}/u/confirm-new-email/%{email_token} كما نصحتَ، لكن في البريد الفعلي يوجد /authorize-email/ في الرابط. لذا أعتقد أن هناك خطأ ما بين لوحة تحكم المسؤول وملف إعدادات ما في أعماق غرفة محركات Discourse. الإصدار المُشغّل هو 2.5.0.beta6

تعديل: الأمر أكثر غرابة: عندما يغير المسؤول عنوان البريد الإلكتروني، تصل رسالة التأكيد إلى العنوان القديم تحتوي على %{base_url}/u/confirm-new-email/%{email_token}، بينما تصل إلى العنوان الجديد تحتوي على %{base_url}/u/authorize-email/%{email_token}.

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

@gh_irina لقد تفقدت هذا، لكنه يحدث أيضًا للمستخدمين الذين يستخدمون اللغة الافتراضية (في حالتنا: الهولندية).

أوه، هذا مزعج. أنا آسف.

لقد واجهت هذه المشكلة للتو في منتدى كنت عضوًا فيه. تمكنت من التحايل عليها عن طريق تعديل الرابط يدويًا. بالنسبة لهذه التغييرات الجذرية، لماذا لا يتم تضمين آلية التقاط للرابط القديم لتنبيه المسؤول؟