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

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

هناك بعض الأمور لا أفهمها، وهناك خطأ واحد (ولهذا السبب أنشر هذا في 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 إعجابات