يبدو أنه عند إعلامي بمراجعة طلب مستخدم جديد لمنتدى، وأرفض الطلب باستخدام خيار “حذف المستخدم”، وأثناء العملية أختار خيار تضمين ملاحظة مرسلة عبر البريد الإلكتروني تشرح سبب عدم نجاح طلبهم، أحصل الآن على استجابة “خطأ 422”.
إذا حذفت الملاحظة، يمكنني حذف المستخدم، كما كان من قبل.
لا تزال الإشعارات المرسلة عبر البريد الإلكتروني التي يولدها المنتدى للمستخدمين المسجلين تعمل بشكل جيد.
إصدار Discourse المثبت حاليًا هو 3.2.0.beta5-dev
سجلات أخطاء المنتدى المتعلقة بتاريخ هذا الحدث (اليوم) أدناه
5
إشعار إيقاف: تم إيقاف `SiteSetting.min_trust_to_edit_post`. يرجى استخدام `SiteSetting.edit_post_allowed_groups` بدلاً من ذلك. (الإزالة في Discourse 3.3) في /var/www/discourse/app/models/co
1:19 مساءً
15
إشعار إيقاف: تحذير: تم إيقاف معلمة البريد الإلكتروني. يجب إرسال جميع طلبات POST إلى هذا المسار باستخدام معلمة email_encoded مشفرة بـ base64 بدلاً من ذلك. تم استلام البريد الإلكتروني و
1:37 مساءً
لا يمكن معالجة البريد الإلكتروني: Email::Receiver::AutoGeneratedEmailError تم الاستلام: من smtp-mx-server-8.servers.netregistry.net (غير معروف [202.124.241.69]) بواسطة nz-mail-receiver.localdomain (Postfix) مع
1:37 مساءً
لا يمكن معالجة البريد الإلكتروني: Email::Receiver::NoBodyDetectedError تم الاستلام: من EUR04-VI1-obe.outbound.protection.outlook.com (غير معروف [104.47.14.50]) بواسطة nz-mail-receiver.localdomain (Postfix) مع
1:39 مساءً
2
ActiveRecord::RecordInvalid (فشل التحقق: سبب الرفض طويل جدًا (الحد الأقصى 500 حرف)) app/models/reviewable.rb:362:in `transition_to' app/models/reviewable.rb:335:in `block in perform
1:51 مساءً
2
فشل معالجة الاستثناء في برمجيات وسيطة الاستثناء: ActiveRecord::RecordInvalid: فشل التحقق: سبب الرفض طويل جدًا (الحد الأقصى 500 حرف)
1:51 مساءً
235
يستهلك Sidekiq الكثير من الذاكرة (باستخدام: 557.11M) لـ 'nzarchitecture.net.nz'، وإعادة التشغيل
1:54 مساءً
38
إشعار إيقاف: تم إيقاف `SiteSetting.min_trust_to_create_tag`. يرجى استخدام `SiteSetting.create_tag_allowed_groups` بدلاً من ذلك. (الإزالة في Discourse 3.3) في /var/www/discourse/lib/guardia
2:06 مساءً
33
إشعار إيقاف: تم إيقاف `SiteSetting.min_trust_to_edit_post`. يرجى استخدام `SiteSetting.edit_post_allowed_groups` بدلاً من ذلك. (الإزالة في Discourse 3.3) في /var/www/discourse/lib/guardian/
2:06 مساءً
لست متأكدًا متى / تحت أي إصدار من برنامج Discourse بدأ هذا الخطأ، حيث لا أتلقى الكثير من الطلبات، ونادرًا ما أحتاج إلى رفض تلك التي أتلقاها، ولكن بالتأكيد لم أواجه مثل هذه المشكلة من قبل، وقد استخدمت نفس الرسالة المنسوخة في إشعارات الرفض السابقة للمتقدمين.
أرى إشارة إلى “سبب الرفض طويل جدًا (الحد الأقصى 500 حرف)”، ونص سبب الرفض القياسي الخاص بي أطول بالفعل من 500 حرف - ولكن هذا بدا أنه يعمل سابقًا.
أعتقد أن هذا مهم لحله، حيث أن تقديم شرح كامل ومرضٍ لأي رفض هو مجاملة أساسية للمتقدمين المحتملين، خاصة إذا لم يكن واضحًا أن الطلب كان بدافع خبيث (إذا كانوا خارج معايير العضوية المقصودة ولكنهم ليسوا روبوتات أو مسوقين أو “جهات فاعلة سيئة” أخرى واضحة).
من الصعب القيام بذلك في حدود 500 حرف إذا أردنا أيضًا تقديم المشورة لأي شخص قد يرغب في إعادة التقديم. إذا لزم الأمر، هل هناك طريقة لزيادة الحد الأقصى للأحرف؟
تم طلب ذلك في مكان آخر، ولكن أود أن أكرر الطلب (إذا رأى أي مطورين هذا) أن يكون لدينا أيضًا قائمة منسدلة بأسباب “رفض” قياسية قابلة للتحرير للاختيار من بينها.
أعتقد أنه تم وضع حدود مؤخرًا على بعض حقول النص هذه، على الرغم من أنها في بعض الحالات كانت تخمينًا معقولًا. سأرى ما إذا كان يمكن زيادة هذا إلى شيء أعلى. هل لديك فكرة عن عدد الأحرف التي ستحتاجها؟
إذا كان بإمكانك إضافة صوتك إلى موضوع موجود، فهذا يساعد في إظهار أنه طلب شائع وغالبًا ما يؤدي إلى تقديمه في قائمة الأولويات.
شكراً لك @JammyDodger، نص سبب الرفض الحالي الخاص بي يبلغ طوله 2211 حرفًا، لأنه يتضمن نصائح تعالج بعض السيناريوهات التي تتضمن بعض الفروق الدقيقة (هذا منتدى متخصص جدًا).
مع تجاهل فكرة قائمة أسباب القائمة المنسدلة الآن، بدلاً من أن يكون هذا السبب حقلًا فارغًا افتراضيًا، هل يمكن أن يكون هذا افتراضيًا باستخدام سلسلة نصية محددة مسبقًا؟ مع مربع اختيار يسمح باستخدام الحقل الفارغ في الوقت المناسب كخيار نص مخصص بديل، في حال نشأت الحاجة؟
حاليًا لا توجد إمكانية لتجاوز ذلك على أساس كل مثيل. سأكون منفتحًا على زيادة الحد قليلاً، ربما إلى 2000 حرف، ولكن أولاً أود رؤية المزيد من الحالات التي يمثل فيها هذا مشكلة في الواقع. في الوقت الحالي، يبدو لي أن تقصير هذه الرسالة (وربما إضافة رابط إلى موضوع يحتوي على بقيتها) منطقي.
أعتقد أنه يجب علينا تحسين واجهة المستخدم المحيطة بهذا بحيث يتم عرض رسالة الخطأ للمستخدم الذي يدخل النص الذي يتجاوز الحد.
قد تعمل صفحة منشورة بشكل جيد جدًا لهذا الغرض إذا كان الموقع يتطلب تسجيل الدخول. يمكن جعلها مرئية للمجهولين حتى لو تم تعيينها على أنها تتطلب تسجيل الدخول.
شكراً لكم يا رفاق. لقد فعلت ذلك، على الرغم من أنني أفضل التخلص من الخطوة الإضافية المطلوبة من المتقدمين الذين يشعرون بالانزعاج بالفعل - خاصة وأن تطبيقات البريد الإلكتروني غالبًا ما تمنع فتح عناوين URL في رسائل البريد الإلكتروني المستلمة افتراضيًا.
أنا حريص على عدم إزعاج أو تنفير أي شخص قد يتبين لاحقًا أنه مستخدم منتديات محتمل دون داعٍ.
وما زلت حريصًا على عدم الاضطرار إلى نسخ ولصق هذه الرسالة يدويًا في كل مرة.
تطبيق Microsoft Outlook الخاص بي هو أحد هذه الأمثلة. يبدو أن هذا السلوك يتأثر بمستوى الثقة الذي يربطه بالرسالة المستلمة.
سيؤدي مستخدم/متقدم جديد إلى تشغيل استجابة بريد إلكتروني آلية قد تبدو مزعجة بعض الشيء إذا لم يقم المستخدم بالفعل بإضافة النطاق المرسل إلى قائمة المرسلين الموثوق بهم - وهي خطوة تبدو أكثر من اللازم بالنسبة لمستخدم جديد يمكن الاعتماد عليه للقيام بها، خاصة إذا لم يتم قبوله كمستخدم بعد.
لقد فعلت ما بوسعي لزيادة سمعة نطاق بريدي الإلكتروني، لكن بعض الرسائل المرسلة من منتداي لا تزال تنتهي في مجلدات البريد غير الهام لبعض المستلمين - وبينما لا يزال من الممكن قراءتها هناك، يتم دائمًا تعطيل الروابط.
لدي نفس الوضع هنا. أحتاج إلى 1200 حرف على الأقل لتقديم الروابط ومعلومات الاتصال. هذا الأمر مزعج بعض الشيء. أيضًا، القدرة على تقسيم النص إلى فقرات ستجعله يبدو أقل آلية. شكرًا لك.
انتظر - من المثير للاهتمام أنه على الرغم من تلقي الخطأ، فقد تم إرسال البريد الإلكتروني بشكل صحيح. لم يتم حذف المستخدم على الرغم من ذلك. أتساءل عما إذا كان ذلك يعني أنني أرسلت حوالي 20 بريدًا إلكترونيًا إلى نفس المستخدم بالأمس؟
أعمل على إصلاح الآن.