لسبب ما، يبدو أن زر “إنشاء حسابك” لم يعد يعمل في مربع حوار التسجيل لمنتدى الخاص بي - النقر عليه بعد إكمال جميع حقول المستخدم (على حد علمي بشكل صحيح) لا يؤدي إلى أي استجابة (حتى رسالة خطأ).
لا يتم إغلاق مربع الحوار، ولا يتم إرسال رسالة التحقق عبر البريد الإلكتروني.
لا توجد مشاكل واضحة في محتوى حقول المستخدم أثناء التسجيل - كلها مكتملة، ولا تظهر أي أخطاء.
تم الاختبار على متصفح Chrome الإصدار 117.0.5938.134 (الإصدار الرسمي)، ومتصفح Edge الإصدار 118.0.2088.33 (الإصدار الرسمي).
مسح ذاكرة التخزين المؤقت للمتصفح لا يبدو أن له أي تأثير.
وظيفة “اختبار البريد الإلكتروني” اليدوية ترسل رسالة إلى عنوان المستخدم المتأثر بشكل جيد.
وظيفة القائمة البريدية للمنتدى للمستخدمين الحاليين تعمل بشكل جيد.
يمكنني أيضًا تسجيل الدخول والخروج من موقع المنتدى بشكل جيد.
لست على علم بأي تغييرات حديثة تم إجراؤها على إعدادات المنتدى (بخلاف تحديثات البرامج)، ولكن لست متأكدًا مما إذا كان هناك حتى إعداد لـ “تجاهل إدخال المستخدم”.
حاول المستخدم المقصود التسجيل عدة مرات وحاولت من جانبي أيضًا، ويمكنني التحقق من المشكلة.
حالياً أقوم بتشغيل أحدث إصدار من Discourse (تم التحديث إلى الإصدار 3.2.0.beta2-dev على أمل حل المشكلة).
لست متأكدًا متى بدأت هذه المشكلة في الحدوث، حيث لم يكن لدينا أي عمليات تسجيل جديدة منذ فترة (ربما أعرف الآن لماذا!).
بافتراض أن المكون الإضافي Multi-select هو سبب المشكلة، يجب أن يكون من السهل جدًا ترحيل الحقول القديمة ‘multiselect-dropdown’ إلى حقول Discourse الجديدة ‘multiselect’. يجب أن يتمكن شخص ما من مجتمع Discourse من مساعدتك في ذلك.
مرحباً - نعم، يبدو أن المكون الإضافي قد تم تجاوزه، لذلك من غير المرجح تحديثه - ولكن المشكلة تكمن في ترحيل بيانات المستخدم التي تم إنشاؤها بواسطة المكون الإضافي إلى حقول بيانات المستخدم الأساسية المقابلة، بحيث يمكن إزالة المكون الإضافي بأمان.
يبدو أن إلغاء تثبيت المكون الإضافي ببساطة يحذف البيانات المرتبطة به (أو على الأقل لم تعد مرئية عند عرض ملفات تعريف المستخدمين)
بافتراض أنني لست المستخدم الوحيد للمكون الإضافي، سيكون من الرائع إذا تم تقديم تحديث نهائي للمكون الإضافي، ليشمل وظيفة “ترحيل”!
لا أرى شيئًا في المكون الإضافي من شأنه أن يتسبب في إزالة حقول المستخدم التي تم إنشاؤها من خلاله من قاعدة البيانات عند إزالة المكون الإضافي من موقع ما. ما أتوقع العثور عليه هو أنه من وحدة تحكم Rails، عند تشغيل:
سيعرض قائمة حقول multiselect-dropdown التي أنشأتها على موقعك.
يمكن استخدام القيم المعينة لـ id لكل من هذه الحقول للعثور على الخيارات التي اختارها كل مستخدم على موقعك لهذا الحقل. على سبيل المثال، إذا كانت المعرفات التي تم إرجاعها هي [1, 2, 3]، فستكون هناك إدخالات مقابلة لـ UserCustomField بالأسماء "user_field_1" و "user_field_2" و "user_field_3". بافتراض أن هذا كله صحيح، فسيكون ذلك كافيًا لشخص ما لترحيل الحقول القديمة إلى حقول جديدة من وحدة تحكم Rails الخاصة بموقعك.
إذا لم يكن مؤلف المكون الإضافي سيتعامل مع هذا، فمن المحتمل أن تضطر إلى توظيف شخص ما للعمل. لاحظ أنني لا أحاول الحصول على عمل هنا، بل أفضل عدم القيام بذلك
قبل إجراء الترحيل، يجب عليك إنشاء حقول Discourse ‘multiselect’ جديدة تحتوي على خيارات تتطابق مع قيم حقول multiselect-dropdown القديمة الخاصة بك. لجعل عملية الترحيل أسهل، سيكون من الجيد استخدام نفس الاسم للحقول الجديدة كما استخدمت للحقول القديمة. بهذه الطريقة، سيعرف الشخص الذي يقوم بالترحيل أن (على سبيل المثال) حقول multiselect-dropdown بالاسم “NZRAB number” يجب ترحيلها إلى حقل ‘multiselect’ الجديد الذي يحمل الاسم “NZRAB number”.
أتفق على أنه سيكون من الأفضل لو قام مؤلف المكون الإضافي بالتعامل مع هذا، ولكن إذا لم يكن ذلك ممكنًا، فما عليك سوى المتابعة وإنشاء حقول ‘multiselect’ جديدة وإزالة المكون الإضافي.
للتحقق فقط - هل يجب أن يسمح الإصدار الأساسي من قائمة Multiselect المنسدلة بتحديد عناصر متعددة من قائمة منسدلة واحدة في وقت واحد بواسطة المستخدم، بنفس الطريقة التي كان عليها المكون الإضافي القديم؟
عند محاولة إضافة حقل مستخدم جديد من نوع “Multiselect dropdown”، لا يوجد سوى خيار واحد “Multiselect dropdown” للاختيار (ربما كنت أتوقع خيارين، إذا كان إصدار المكون الإضافي مختلفًا عن الإصدار الأساسي).
الآن، إذا اخترت نوع حقل Multiselect dropdown هذا، وحاولت إضافة بيانات إلى ملف تعريف مستخدم به، فإنه يقبل تحديد مستخدم واحد فقط، وليس تحديدات متعددة في وقت واحد - لذلك يبدو إما أن الإصدار الأساسي لنوع حقل Multiselect drop down لديه وظائف محدودة وقد حل محل إصدار المكون الإضافي، أو أن هناك بعض التفاعل مع إصدار المكون الإضافي الذي يعطل أي إصدار أراه؟
من الممكن أن تكون واجهة المستخدم مختلفة عما كان يفعله المكون الإضافي، ولكن نأمل أن تكون النتائج هي نفسها.
هل يمكنك التأكيد على أنه مع تثبيت المكون الإضافي، يمكنك رؤية القيم التي أدخلها المستخدمون للحقول التي تم إنشاؤها بواسطة المكون الإضافي إذا قمت بزيارة صفحة ملفهم الشخصي؟
تعديل: @Paul_King، أدرك أنني ربما كنت متفائلاً للغاية بشأن ترحيل البيانات. بدون الوصول إلى وحدة تحكم Rails في موقعك، فإن أسهل طريقة للحصول على فكرة عما يحدث هي التحقق من كيفية حفظ الحقول القديمة عن طريق تشغيل استعلام Data Explorer. إذا لم يكن لديك هذا المكون الإضافي مثبتًا على موقعك، فقد يكون من المفيد إضافته.
إذا كان المكون الإضافي Data Explorer مثبتًا على موقعك، فحاول تشغيل الاستعلام التالي:
SELECT * FROM user_fields
نأمل أن يُرجع هذا الاستعلام بعض النتائج مع تعيين field_type الخاص بها إلى “multiselect-dropdown”. إذا كان الأمر كذلك، فيجب أن يكون ترحيل البيانات مباشرًا إلى حد ما.
مثالك الذي يوضح تشغيل القائمة المنسدلة متعددة الاختيارات يتطابق مع الطريقة التي كانت تعمل بها لدي، مما يبدو واعدًا من حيث استعادة الوظائف الأصلية.
حاليًا، يبدو أن وظائف المكون الإضافي القديم أو الإصدار الجديد الأساسي لا تعمل بشكل صحيح - الحقل بأكمله لا يظهر الآن على الإطلاق في شاشة تحرير ملف تعريف المستخدم، على الرغم من أن القيم التي أدخلها المستخدم في الأصل باستخدام المكون الإضافي القديم تظهر لمستخدم ينقر على صورة مستخدم أخرى ولكن مع ظهور البيانات الأصلية مع أقواس مربعة وعلامات اقتباس على كلا الجانبين.
نعم، تُرجع هذه الاستعلامات هذا النوع من الحقول. هل من الممكن أن ينشأ الارتباك بسبب الاسم القديم للمكون الإضافي واسم النواة في Discourse لإصداراتهما الخاصة من نوع حقل مستخدم متعدد الاختيارات المتطابق؟
هذا ليس مفاجئًا. هذا يعني أن البيانات اللازمة للترحيل موجودة في قاعدة البيانات، ولكن من المحتمل أنها في شكل لن يجعل الترحيل سهلاً كما كنت آمل.
لتأكيد ذلك، حاول تشغيل استعلام مستكشف البيانات التالي:
SELECT * FROM user_custom_fields
WHERE name = 'user_field_1'
ORDER BY user_id
المعلومات المفيدة من نتائج هذا الاستعلام ستكون ما تم تعيينه في عمود value. من الناحية المثالية، ستبدو النتائج مشابهة لهذا، مع إدخال منفصل لكل خيار اختاره المستخدم:
أشك في أن ما ستجده هو أن قيم كل خيار اختاره المستخدم ستكون موجودة في نفس الصف. على سبيل المثال، [this, that] أو \"[this, that]\". إذا كان هذا صحيحًا، هل يمكنك نشر بعض إدخالات القيمة؟
قد يستغرق الأمر بعض التجربة والخطأ لمعرفة كيفية تحليل القيم إلى الشكل الذي تتوقع أن يجده Discourse.
يبدو أن هذا سيعمل. قد يحتاج جاي، أو شخص مماثل، إلى التوظيف للقيام بالعمل.
من المفترض أن يكون من الممكن تقنيًا إجراء التغييرات من وحدة تحكم Rails. ستعتمد صعوبة هذا النهج على كيفية تعيين حقول value للحقول المخصصة للمستخدم القديمة “multiselect-dropdown”. إذا كان هناك خيار واحد مخزن لكل صف، فسيكون من السهل إنشاء إدخالات UserCustomField جديدة من الإدخالات القديمة. إذا تم تخزين خيارات متعددة في كل صف، فقد يصبح الأمر صعبًا بعض الشيء.
كان تنسيق البيانات مثيرًا للاهتمام - كان في شكلين مختلفين تغيرا في يوم واحد. بدأت كالتالي:
this
that
وفي يوم ما تغيرت فجأة إلى
this,that
لقد قمت ببعض الحيل الملتوية في جداول البيانات لتحويل البيانات إلى كيفية حقول التحديد المتعدد الجديدة (كما هو موضح أعلاه). للأسف، النص البرمجي لا يمكنه (حتى الآن) التعامل مع التحديد المتعدد. هل هناك طلب سحب (PR)؟
على الرغم من أنني أستطيع تجاوز / اختراق الأمر للقيام بالمهمة، أعتقد:
المرحلة الأولى: جميع المستخدمين الذين لديهم إدخال واحد باستخدام النص البرمجي الحالي
المرحلة الثانية: جميع المستخدمين الذين لديهم إدخالات متعددة باستخدام نص برمجي مخترق يجبر على إنشاء صفوف جديدة.
لاحقًا…
لقد نجحت خطتي الماكرة.
هذا هو النص البرمجي المخترق للمرحلة الثانية:
# frozen_string_literal: true
require "csv"
desc "Import user fields"
task "multi_user_fields:import_csv", [:filename] => [:environment] do |_task, args|
puts "Filename: #{args[:filename]}"
data = CSV.read(args[:filename], headers: true );
data.each_entry do |row|
puts "doing row."
row.to_h.each do |x|
user_id = row['user_id']
if x.first == 'user_id'
u = User.find(user_id)
puts "Got user: #{u.username}"
else
name = x.first
val = row[x.first]
ucf = UserCustomField.find_by(user_id: row['user_id'], name: name)
if val
puts "Creating UCF: #{row['user_id']} Name: #{name}, value: #{val}"
UserCustomField.create(user_id: user_id, name: name, value: val)
end
end
end
end
end
@pfaffman - ما مدى سهولة تحديث النص البرمجي الفعلي للتعامل مع حقول التحديد المتعدد للآخرين الذين يعبثون بحقول المستخدم المخصصة (UCFs) في المستقبل؟
من جانبي، يسعدني جدًا أن أبلغ أن ناثان وعمليته (بما في ذلك الحلول المؤقتة) قد نجحت تمامًا.
لقد تأكدت من أن مربع حوار التسجيل يعمل الآن، ويمكن للمستخدمين المقصودين تحديد إجابات متعددة مرة أخرى من خيارات القائمة المنسدلة، ويمكنهم عرضها وتعديلها مرة أخرى كمستخدمين معتمدين، وتمت إزالة المكون الإضافي القديم للاختيار المتعدد بنجاح.
شكرًا لـ @nathank و @omarfilip و @simon و @RGJ على تخصيص الوقت للنظر في هذه المشكلة ومشاركة معرفتكم ورؤيتكم - المزيد من الأدلة، إذا كانت هناك حاجة إليها، على مدى روعة هذا المجتمع!
.