الحل موجود حرفياً في المنشور الذي يسبق منشورك مباشرة. 
يجب علينا إصلاح البرنامج النصي. ربما يمكنك إنشاء طلب سحب (PR) يحل المشكلة للجميع؟
شكرًا، لقد تم حل المشكلة، أنا آسف لذلك. كعقاب على عدم قدرتي على القراءة، فتحت Added duplication to name to prevent modification of frozen string exception by adam-skalicky · Pull Request #30325 · discourse/discourse · GitHub لإنقاذ أي شخص آخر من عار طرح سؤال غبي.
إعجاب واحد (1)
هل يقوم هذا النص البرمجي للاستيراد بجعل Discourse يكرر ترابط رسائل البريد الإلكتروني في Mailman 2 بأي شكل من الأشكال (على سبيل المثال، باستخدام السهم الصغير في Discourse للإشارة إلى “رد على”) أم أنه يعتمد فقط على التسلسل الزمني (لكل سلسلة بناءً على Message-ID و In-Reply-To و References)؟
إعجاب واحد (1)
نعم، يفعل
3 إعجابات
رائع. لم تحصل العديد من رسائل البريد الإلكتروني في قائمتي البريدية على رؤوس In-Reply-To و References التي يجب أن تكون موجودة بها، لذلك قد يتم استيرادها كمواضيع جديدة بدلاً من مجرد ردود. حسب ذاكرتي، يستخدم البرنامج النصي تلك الرؤوس أو رؤوس الموضوع (وليس كلاهما).
أعتقد أنني سألت هذا في الماضي البعيد، ولكن هل هناك أي طرق غير يدوية لإضافة هذه الرؤوس إلى ملف MBOX و/أو إعادة ترتيب رسائل البريد الإلكتروني بطريقة أخرى قبل أو بعد الاستيراد إلى Discourse؟
من الممكن الآن دمج المواضيع والحفاظ على الترتيب الزمني، لذا ربما يكون هذا هو الحل. لن يكون لديهم سوى السهم الصغير في Discourse الذي يشير إلى من كان الرسالة رداً عليه.
إعجاب واحد (1)
يحتوي برنامج استيراد mbox النصي على مرحلتين. الأولى هي الفهرسة وتنتج قاعدة بيانات SQLite. يمكنك إما تعديل البيانات في SQLite قبل الاستيراد، أو تعديل برنامج Ruby النصي.
كل سحر الفرز/التجميع حسب الموضوع أو الرؤوس يحدث هنا:
يمكنك إضافة منطق التجميع الخاص بك إذا كنت تعرف كيف تريد تجميع رسائل البريد الإلكتروني.
3 إعجابات
سيستغرق الأمر بعض الوقت قبل أن أفكر حتى في شيء معقد كهذا!
في https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/Mailman/Archiver/pipermail.py#L669 يبدو أن Pipermail الخاص بـ Mailman 2 يبحث عن ما يلي حسب الأولوية:
- In-Reply-To.
- References.
- أقدم بريد إلكتروني بموضوع مطابق.
يبدو هذا المزيج من الأساليب مثاليًا. في الحالة الثالثة، قد يكون من المنطقي أن لا يستخدم Discourse سهم “رد على”.
من الذاكرة، لم يأخذ Hyperkitty الخاص بـ Mailman 3 الموضوع في الاعتبار على الإطلاق، وهو ما لم يكن جيدًا.
إعجابَين (2)
عذرًا على مقاطعتي بهذا السؤال الغبي المحتمل، ولكني لم أتمكن من العثور على إجابة واضحة هنا. أود أن أعرف ما إذا كانت عملية الاستيراد تنشئ مستخدم Discourse جديدًا لكل بريد إلكتروني، مع إزالة التكرار بالطبع، أو ما إذا كانوا جميعًا يدخلون كمستخدم نظام واحد. لدي قائمة بريدية تحتوي على 20 عامًا من المشاركات وهي كبيرة جدًا ويصعب التجربة عليها. وأيضًا، ماذا عن الردود في القائمة الأصلية؟ هل يتم تجميعها في سلاسل مترابطة؟
نعم، يتم إنشاء المستخدمين، واحد لكل عنوان بريد إلكتروني.
تمكنت من إجراء عملية Google Takeout لمجموعات Google الخاصة بي، ثم قمت برفع ملفات .mbox واستيرادها.
كانت هذه الخطوات مفيدة لربط data/folder بفئة موجودة، لكن يجب تنفيذ ذلك داخل حاوية import، وليس حاوية app كما هو موضح في هذا التقرير:
./launcher enter import
rails c
# استخدم معرف الفئة الظاهر في عنوان URL، على سبيل المثال
# يكون 16 عندما يبدو مسار الفئة كالتالي: /c/soccer/16
category = Category.find(16)
# استخدم اسم المجلد الذي تُخزَّن فيه ملفات mbox. على سبيل المثال،
# عندما تكون الملفات مخزنة في import/data/foo، يجب استخدام "foo" كاسم للمجلد.
category.custom_fields["import_id"] = "soccer"
category.save!
لدي بالفعل مستخدمون في Discourse قاموا بالهجرة بأنفسهم، لذا فشل سكريبت الاستيراد في إنشاء جهات اتصال لهم (وهو أمر على الأرجح ليس سيئًا)، لكن الرسائل المستوردة التي كان هؤلاء المستخدمون الحاليون في Discourse مشاركين فيها تظهر المرسل باسم system بدلاً من اسمهم.
هل توجد أي طريقة لجعل النظام يربط المستخدمين الحاليين برسائلهم المستوردة؟
لقد قمت حاليًا بإلغاء كل شيء عن طريق الاستعادة من نسخة احتياطية حديثة. أنا مستعد للمحاولة مرة أخرى مع بعض التوجيهات للتعامل مع مستخدمي Discourse الحاليين ورسائلهم المستوردة.
تحديث:
ساعدني Claude في حل مشكلة ربط المستخدمين الحاليين، حيث يجب تشغيل هذه الحلقة في وحدة تحكم Rails، بالإضافة إلى الكود المذكور أعلاه:
User.where("id > 0").find_each do |u|
email = u.email.downcase
unless u.custom_fields["import_id"].present?
u.custom_fields["import_id"] = email
u.save_custom_fields
end
end
إعجاب واحد (1)