تغيير بريد المستخدم الإلكتروني

أنا مرتبك قليلاً بشأن العملية التي تتم عندما يقوم المشرف بتغيير عنوان بريد إلكتروني للمستخدم.

هناك بعض الأمور التي لا أفهمها ببساطة، كما توجد علة واحدة (ولهذا السبب أنشر هذا في Contribute > Bug وليس في Support)

  • وفقًا لـ طلب الدمج هذا، يجب أن تعمل العملية على النحو التالي:

عندما يقوم المشرف بتغيير بريد المستخدم الإلكتروني من صفحة تفضيلات ذلك المستخدم:

  • لن يُرسل إلى المستخدم بريد إلكتروني لتأكيد تغيير بريده الإلكتروني. بل سيُرسَل إليه بريد لإعادة تعيين كلمة المرور حتى يتمكن من تعيين كلمة مرور لحسابه على عنوان البريد الإلكتروني الجديد.
  • سيُرسَل إلى المستخدم أيضًا بريد إلكتروني إلى عنوانه القديم لإعلامه بأنه تم تغييره.

#1 لا أفهم سبب إرسال بريد إعادة تعيين كلمة المرور («حتى يتمكن من تعيين كلمة مرور لحسابه»). أليس من الضروري أن يغير المستخدم كلمة مروره؟ وتجربة المستخدم مربكة؛ فالمتوقع من المستخدم عدم تلقي بريد لإعادة تعيين كلمة المرور، ولا يوجد نص مصاحب، بل يُكتفى بعبارة «طلب شخص ما إعادة تعيين كلمة مروره على [اسم المنتدى]».

#2 يُرسل بريد إعادة تعيين كلمة المرور هذا إلى العنوان القديم بدلًا من عنوان البريد الجديد.

رغم تحديث بريد المستخدم في update_user_email في السطر 46، فإن كائن @user لا يتم إعادة تحميله ولا يزال يحتوي على عنوان البريد القديم.

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

#4 لماذا لا يحتاج المستخدم إلى تأكيد عنوان بريده الإلكتروني الجديد؟ يشير طلب الدمج إلى هذا الموضوع، لكن يبدو أن هناك العديد من المشاركات المفقودة فيه. ومع ذلك، لا يزال الموضوع يذكر «بالنسبة للمستخدم العادي، فإن عنوان البريد الإلكتروني الوحيد الذي يجب التحقق منه هو عنوان البريد الإلكتروني الجديد». تعديل: انتظر، انظر إلى #6 / #7.

#5 تُستخدم هذه العملية التي يقوم فيها المشرف بتغيير بريد المستخدم عادةً عندما لا يكون عنوان البريد الإلكتروني القديم متاحًا بعد (أفترض ذلك). فلماذا لا يزال يتم إرسال إشعار إلى العنوان القديم؟

#6 عندما يحاول هذا المستخدم تسجيل الدخول، تظهر نافذة منبثقة

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

  • لم يصل مثل هذا البريد
  • يُذكر عنوان البريد الإلكتروني القديم

عند الضغط على زر إعادة الإرسال، تظهر الرسالة:

لقد أرسلنا بريد تفعيل آخر إلى عنوان البريد الإلكتروني الجديد. قد يستغرق وصوله بضع دقائق؛ تأكد من مراجعة مجلد الرسائل غير المرغوب فيها.

#7 يصل بريد التفعيل هذا بالفعل إلى عنوان البريد الجديد وعنوانه هو «تأكيد حسابك الجديد» (وليس «تأكيد عنوان بريدك الإلكتروني الجديد»)

أليس من المفترض أن يكون الأمر كالتالي ببساطة:

يُرسَل بريد واحد إلى عنوان البريد الجديد، ينص على «تم تغيير عنوان بريدك الإلكتروني بواسطة [اسم المشرف]. يرجى النقر على الرابط التالي للتأكيد [الرابط]."

تعديل: #8 يمكن تغيير عنوان البريد الإلكتروني من قبل المشرف من الملف الشخصي العام للمستخدم (/u/username) ولكن ليس من صفحة المشرف الخاصة بذلك المستخدم (/admin/users/id/username). هذا أمر غير بديهي.

10 إعجابات

هل يمكننا إعادة إنتاج هذا @tshenry؟ هل حدث تراجع هنا؟

إعجابَين (2)

سأبدأ بتوضيح التدفق الحالي كما أراه يحدث (معظمه، إن لم يكن كله، يتوافق مع ما ذكره @RGJ):

  1. يذهب المسؤول إلى تفضيلات مستخدم غير من الطاقم ويغير عنوان بريده الإلكتروني:

    بمجرد الإرسال، يرى المسؤول الرسالة التالية:

    لقد أرسلنا بريدًا إلكترونيًا إلى ذلك العنوان. يرجى اتباع تعليمات التأكيد.

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

    [Demo] تم تغيير عنوان بريدك الإلكتروني

    هذه رسالة آلية لإبلاغك بأنه تم تغيير عنوان بريدك الإلكتروني الخاص بـ
    Demo. إذا كان ذلك خطأً، يرجى الاتصال
    بمسؤول الموقع.

    تم تغيير عنوان بريدك الإلكتروني إلى:

    new@email.com

    [Demo] إعادة تعيين كلمة المرور

    طلب شخص ما إعادة تعيين كلمة مرورك على Demo.

    إذا لم تكن أنت، يمكنك تجاهل هذا البريد الإلكتروني بأمان.

    انقر على الرابط التالي لاختيار كلمة مرور جديدة:
    https://example.discourse.site/u/password-reset/74d53d7d2cf20dsbc360614844c653s2

  3. اختبرت ثلاثة سيناريوهات منفصلة من هذه النقطة. كل نقطة تعبر عن سيناريو مستقل:

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

    • يحاول المستخدم تسجيل الدخول باستخدام اسم المستخدم أو عنوان البريد الإلكتروني الجديد ويتلقى ما يلي:

      الخيار 1: عند الضغط على إعادة الإرسال، تظهر الرسالة التالية (لاحظ أنها تذكر عنوان البريد الإلكتروني الجديد هذه المرة):

      يتم بالفعل إرسال بريد إلكتروني إلى عنوان البريد الإلكتروني الجديد:

      [Demo] تأكيد حسابك الجديد

      مرحبًا بك في Demo!

      انقر على الرابط التالي لتأكيد وتفعيل حسابك الجديد:
      https://example.discourse.site/u/activate-account/74d53d7d2cf20dsbc360614844c653s2

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

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

      الخيار 2: عند الضغط على زر تغيير عنوان البريد الإلكتروني، يظهر ما يلي. يكون زر تحديث عنوان البريد الإلكتروني معطلًا عندما يكون عنوان البريد الإلكتروني الجديد في حقل النص، مما يوحي بأن البريد الإلكتروني الجديد نشط بالفعل (لكن ذلك لا يبدو صحيحًا).

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

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

@martin أعرف أنك قمت بالتلاعب بهذا الجزء من النواة في الماضي. هل يمكنك إبداء رأيك هنا عندما يتاح لك وقت؟

9 إعجابات

لماذا حدث هذا التراجع؟ :thinking:

تعديل: يمكنني أيضًا تأكيد أنه حدث تراجع. عند تعديل بريد إلكتروني لمستخدم عادي، يتم إرسال التأكيد وما إلى ذلك إلى البريد الإلكتروني القديم. لم يكن هذا هو الحال في الماضي..

4 إعجابات

تلك المشاعر المزعجة من الألفة عندما تقرأ وصف طلب السحب المقتبس وتدرك أنك أنت الجاني…

شكرًا للتعليمات التفصيلية @tshenry و @RGJ، سأجعل إصلاح هذا الأمر في مقدمة قائمة أولوياتي هذا الأسبوع.

4 إعجابات

حسناً، لقد فهمت الأمر الآن، وقمت بالرجوع إلى الموضوع القديم لحذف التعليقات للحصول على السجل. لقد عثرت على هذا من @sam والذي أتذكره الآن:

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

إذن نحن نقول أنه بما أن المشرف هو من يغير البريد الإلكتروني، فيجب إرسال بريد إلكتروني لإعادة تعيين كلمة المرور، لأنه إذا كان المستخدم يملك حق الوصول إلى البريد الإلكتروني القديم، لكان بإمكانه ببساطة… تسجيل الدخول وقيام بذلك بنفسه؟ ولكن بريد إعادة تعيين كلمة المرور يعمل أيضاً كـ تأكيد. بدون إكمال عملية إعادة تعيين كلمة المرور (وهو أمر مستحيل حالياً لأنه يُرسل إلى البريد القديم) لا يتم “تأكيد” البريد الجديد، وهذا ما يؤدي إلى ظهور هذه النافذة المنبثقة:

المشكلة التي يتم فيها إرسال بريد إعادة تعيين كلمة المرور إلى العنوان القديم يمكن إصلاحها بسهولة، وسنصل على الأقل إلى حالة يمكن فيها متابعة عملية إعادة التعيين:

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

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

4 إعجابات

انتظر. لا أفهم هذا.

هناك فرق بين قدرة المستخدم على الوصول إلى البريد الإلكتروني القديم وبين حاجة المستخدم إلى إعادة تعيين كلمة المرور لحسابه في Discourse. الأولى لا تعني الثانية مطلقًا؛ فهما حالتان مختلفتان تمامًا.

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

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

4 إعجابات

قد يكون الأمر مرتبطًا بـ:

عندما يحاول أحد مستخدمي المنتدى إعادة تعيين كلمة المرور اليوم (مع تشغيل أحدث إصدار من Discourse حتى صباح اليوم)، يتلقى البريد الإلكتروني، لكنه يواجه خطأً عند النقر على الرابط الموجود في البريد:

يظهر هذا الخطأ في متصفحات متعددة، وهو لا يستخدم أي مانع للإعلانات.

عندما أذهب إلى صفحة التفضيلات لحسابه وأضغط على “إرسال بريد إعادة تعيين كلمة المرور”، أواجه رسالة خطأ هناك أيضًا:

قبل أن يظهر “(خطأ)” بجانب الزر، يومض النص “(جاري إرسال البريد الإلكتروني)” لفترة وجيزة. يبدو أن البريد الإلكتروني لم يُرسل في الواقع. يمكنني التحقق من أن رسائل المنتدى الأخرى تُرسل بشكل طبيعي اليوم.

كانت هذه الميزة تعمل بشكل صحيح سابقًا… ويبدو أنها تعطلت خلال الأسبوع الماضي في وقت ما.

تحقق من سجلات أخطاء Discourse في متصفح الويب بعد تسجيل الدخول كمسؤول، يجب أن تجد تقرير خطأ يحتوي على تفاصيل أكثر.

إليك سجل الخطأ:

398 استثناء المهمة: حجم مصدر النسخ المحدد أكبر من الحجم الأقصى المسموح به لمصدر النسخ: 5368709120

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call`

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call`

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call`

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call`

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call`

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call`

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call`

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call`

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/response_target.rb:23:in `call`

aws-sdk-core-3.99.1/lib/seahorse/client/request.rb:70:in `send_request`

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object`

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:61:in `block in vacate_legacy_prefix`

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `each`

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `vacate_legacy_prefix`

/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff`

/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute`

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform`

rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection`

/var/www/discourse/app/jobs/base.rb:221:in `block in perform`

/var/www/discourse/app/jobs/base.rb:217:in `each`

/var/www/discourse/app/jobs/base.rb:217:in `perform`

sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job`

sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process`

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke`

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call`

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke`

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke`

sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process`

sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch`

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local`

sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch`

sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>`

sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch`

sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats`

sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch`

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call`

sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch`

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global`

sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch`

sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with`

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare`

sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch`

sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process`

sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one`

sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run`

sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog`

sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread`
إعجاب واحد (1)

لا، هذا غير مرتبط تمامًا.
حاول مسح السجلات وإجبار حدوث هذا الخطأ، ثم تحقق من السجلات مرة أخرى.

عندها تظل السجلات فارغة بعد حدوث الخطأ.

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

أود من @sam أن يشارك برأيه حول عملية/تدفق جديد، لأن سام تحدث في الأصل عن المنطق الكامن وراء تدفق إعادة تعيين كلمة المرور:

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

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

إعجابَين (2)

نعم، لا أستطيع أن أرى سببًا يربط بين هذين الأمرين على الإطلاق؟

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

أرى دمجًا جديدًا واحدًا لطيفًا سيسعد به الجميع :smiley:

3 إعجابات

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

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

4 إعجابات

لقد دمجتُ هذا الطلب (PR) الذي يقوم بالآتي:

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

آمل أن يجعل هذا العملية أكثر وضوحًا!

4 إعجابات