هناك عدة طرق مختلفة لربط المشاركات الأصلية، ويتم تخزين الارتباط عبر جدول PostReply، حيث يمثل reply_post_id المشاركة التي تقوم بالرد، وpost_id يشير إلى الأصل. تستخدم رسائل البريد الإلكتروني الواردة In-Reply-To لربط هذه، ومن واجهة مستخدم Discourse، إذا قمت باقتباس مشاركات متعددة، يتم إنشاء سجلات PostReply متعددة، وإذا استخدمت زر “رد” على مشاركة واحدة، فسيتم استخدامه لإنشاء سجل PostReply.
نعم، آسف، كان يجب أن أشير إلى ذلك، لن يتم استخدام add_identification_field_headers بعد الآن، كل شيء موجود في add_experimental_identification_field_headers، وهو الرمز الجديد. شكرًا لك على تقديم تعليقات على الرمز نفسه، لم أكن أتوقع ذلك! سأعمل عليها اليوم.
@cameron-simpson أعتذر، أعتقد أنك ربما راجعت التزامًا سابقًا في علاقة الطلب هذه. لقد قمت الآن بإعادة تأسيس الشفرة الخاصة به ودفعتها مرة أخرى للحصول على التزام واحد بجميع أحدث الشفرات التي كنا نختبرها على هذا الموقع التجريبي. نأمل أن تكون رسالة الالتزام هناك مفيدة ومنطقية.
بالنسبة لـ References، إذا كان المستخدم يرد على منشور، فأنا أستخدم السلسلة الكاملة لمعرفات الرسائل من المنشور الأصلي إلى المنشور الأصل في الترتيب. على سبيل المثال، إذا كانت جميع هذه المنشورات عبارة عن سلسلة مباشرة من الردود:
إذا تم إنشاء منشور جديد لا يرد مباشرة على المنشور أعلاه، على سبيل المثال المنشور 6 – discourse/post/505@test.site، فسيكون معرف رسالته In-Reply-To هو <discourse/post/500@test.site> (المنشور الأصلي)، وسيكون References هو <discourse/post/500@test.site> وهو المنشور الأصلي أيضًا.
يرجى إعلامي إذا كان هذا غير صحيح ويمكنني المراجعة.
بواسطة مارتن برينان عبر Discourse Meta في 23 أغسطس 2022 23:59:
@cameron-simpson أعتذر، أعتقد أنك ربما راجعت التزامًا سابقًا في طلب السحب هذا. لقد قمت الآن بإعادة تأسيس الكود الخاص به ودفعت مرة أخرى للحصول على التزام واحد مع كل أحدث الكود الذي كنا نختبره على موقع الاختبار هذا. نأمل أن تكون رسالة الالتزام هناك مفيدة ومنطقية.
سألقي نظرة أخرى، شكرًا.
بالنسبة لـ “References”، إذا كان المستخدم يرد على منشور، فأنا أستخدم السلسلة الكاملة لمعرفات الرسائل من المنشور الأصلي وصولاً إلى المنشور الأب بالترتيب. على سبيل المثال، إذا كانت كل هذه المنشورات عبارة عن سلسلة مباشرة من الردود:
إذا تم إنشاء منشور جديد لا يرد مباشرة على المنشور أعلاه، على سبيل المثال المنشور 6 – discourse/post/505@test.site، فسيكون معرف الرسالة “In-Reply-To” الخاص به هو <discourse/post/500@test.site> (المنشور الأصلي)، وسيكون “References” هو <discourse/post/500@test.site> وهو المنشور الأصلي أيضًا.
شكرا لك. لقد نسيت أيضًا أن أذكر أننا بالفعل بحاجة إلى الذهاب إلى قاعدة البيانات لإعادة إنشاء سلسلة References بناءً على سجلات PostReply، سترى ذلك في أحدث تثبيت.
@cameron-simpson أود أن أبدأ عملية المراجعة الداخلية لهذا الرمز الأسبوع المقبل (بالإضافة إلى مجرد صقل عام لما قمت به)، حيث سأذهب في إجازة في اليوم الثالث. بهذه الطريقة، إذا اكتملت المراجعة، يمكنني دمجها ونشرها بمجرد عودتي. إذا كان لديك أي ملاحظات أخرى، فيرجى إخباري بذلك قبل ذلك الحين، وإلا سأفترض أن كل شيء على ما يرام (وهو ما بدا عليه الحال خلال اختبارنا بالأمس ).
أعتقد أن الأمور جيدة في الغالب. ملاحظاتي من المسح اليدوي لسلسلة البريد الإلكتروني من جهتي، والتي قمت بمسحها يدويًا في الغالب للعناوين:
موضوع لاختبار الترابط 2022-08-23
منشور معرف الرسالة التفاصيل
59/1 98 OP مواضيع جديدة لاختبار ترابط البريد الإلكتروني
59/11 109 الرد على الموضوع في الرد على 98 مرجع 98
59/2 100 الرد على الموضوع في الرد على 98 مرجع 98
59/3 عبر البريد الإلكتروني uuid@discourse نعم مرحبًا في الرد على 100 مرجع 98،100
لم يتم ملاحظته كرد في واجهة الويب
؟؟؟ لي عبر البريد الإلكتروني ...kr@cskk يسعدني أن أكون هنا في الرد على uuid@discourse لا مراجع
لم يتم ملاحظته كرد في واجهة الويب
59/10 108 الرد على المنشور السابق في الرد على ...kr@cskk مرجع 98،100،0aa@discourse،kr@cskk
59/5 103 شكرًا كاميرون في الرد على kr@cskk مراجع 98،100،0aa@discourse،kr@cskk
؟؟؟104 لي عبر البريد الإلكتروني ...zp@cskk في الرد على 103 لا مراجع
لم يتم ملاحظته كرد في واجهة الويب
59/7 105 لا مشكلة في الرد على zp@cskk مراجع 98،100،00a@discourse،kr@cskk،103،zp@cskk
تم النشر على الويب، الرد على 104؟ المعروف أيضًا باسم zp@@cskk
لم يتم ملاحظته كرد في واجهة الويب (إذًا، موضوع جديد؟)
يقتبس kr@cskk "يسعدني أن أكون هنا"
بحاجة إلى مراجعة
59/9 107 متوقع أو خطأ في الرد على 106 مرجع 98،100،0aa@discourse،kr@cskk،103،zp@cskk،105،106
يقتبس 59/8
ملاحظات:
- لا تظهر ردود البريد الإلكتروني كردود في واجهة الويب
- الردود المتعددة على الويب تحصل فقط على معرف رسالة واحد في الرد على
- لا يتلقى المستخدمون نسخًا من رسائل البريد الإلكتروني الخاصة بهم (بريد إلكتروني أو ويب)، سيكون من الجيد وجود خيار في التفضيلات لهذا
- تبدو معرفات الرسائل على الويب كـ forum post.id، سيكون من الأفضل لو كان topic.id/in-topic.id لتتبع أسهل في العناوين
باختصار: لم أجد أي عناوين غير صحيحة، لكن لاحظت بعض أوجه القصور أعلاه.
لم تتح لي الفرصة لمراجعة الكود المحدث الخاص بك، ولكن من الناحية الوظيفية تبدو الأمور صحيحة.
أوه، لم أعتقد أن هذا مطلوب، لذا إذا قمت بالرد على N منشورات عبر الويب، فيجب أن تظهر جميع معرفات الرسائل لتلك المنشورات في رأس In-Reply-To، ثم يتبع References المنطق الحالي للموضوع من OP إلى الأصل الوحيد (في حالتنا اخترت أحدث منشور تم إنشاؤه كأصل وحيد)؟
نعم، هذا حسب التصميم لعدم إرسال أشياء “شاهدتها” بالفعل، يمكننا طرح ذلك في مهمة أخرى لمعرفة ما إذا كان هناك طلب على هذا من المزيد من المستخدمين.
المشكلة مع معرف الموضوع هي أنه هش للغاية وغير محدد/فريد بما فيه الكفاية، كما أنه سيبدو مربكًا بعض الشيء عندما يتم نقل منشور بين المواضيع. ربما يمكننا تضمين رأس مخصص في البريد الإلكتروني، على سبيل المثال X-Discourse-Topic-ID أو شيء من هذا القبيل (إذا كان ذلك مسموحًا به) للسماح بتتبع أسهل بصريًا؟
آه. بينما أنا، كشخص غير ملم بالمنتديات عبر البريد الإلكتروني، كنت أتوقع هذا المؤشر على كل رد لأنني لا أفكر في هذا كتخطيط للمراسلة الفورية (ربما). لذا فإن توقعاتي تختلف عما اخترت القيام به.
إنه ليس مطلوبًا. فكر في الأمر على أنه “جودة الخدمة”. أنت تقوم صراحةً بما يلي:
ويمكنك فقط إسقاط [0] هناك. يمكن للعملاء بعد ذلك استخدام معرف رسالة واحد أو القيام بشيء غريب جدًا حسب رغبتهم وسيكون كل شيء صالحًا.
“يجب” كلمة قوية. يمكنك تضمين جميع معرفات الرسائل إذا كانت متاحة بسهولة. لست ملزمًا بذلك، والرمز صالح كما هو.
نعم. أعرف أنني أحب ذلك بنفسي حتى أعرف أن منشوري وصل إلى القائمة/المنتدى - البريد الإلكتروني يعتمد بشكل كبير على قائمة الانتظار وبعض معالجات البريد لمقدمي خدمة الإنترنت (آه، شركة اتصالات أسترالية كبيرة، آه) تكون … غير موثوقة، بطيئة، إلخ. في بعض الأحيان رأيت أشخاصًا آخرين يرغبون في ذلك (في القوائم، ولكن هذا هو الوضع الذي نتحدث عنه فعليًا هنا). يجب أن يكون الإعداد الافتراضي لمثل هذا الخيار هو “خطأ”.
بصفتي شخصًا تقنيًا، أحب أن أكون قادرًا على الحصول على موجز غير مفلتر على الأقل حتى أتمكن من اتخاذ قراراتي الخاصة.
نظرًا لأن Message-ID هو في الأساس غير شفاف/يتم تعيينه مرة واحدة، فأنا لا أرى ذلك مشكلة ما لم يكن هناك مجال لإعادة إصدار نفس معرف الرسالة - إذا كانت جميع عداداتك متزايدة بشكل صارم، فلن أتوقع حدوث ذلك. لقد وجدت فقط أنه كان مملاً للغاية لمطابقة post.id على سبيل المثال 98 مع الموضوع/المنشور على سبيل المثال 59/1. سيكون من المفيد أن يكون لديك شيء مثل category.id/topic.id/post-in-topic.id هناك بدلاً من 98.
سيكون ذلك كافيًا أيضًا. هذه مجرد راحة في جانب رؤوس تصحيح الأخطاء.
هذا لا يزال هو الكود القديم الذي تنظر إليه هناك، تحتاج فقط إلى النظر إلى add_experimental_identification_field_headers. لكن وجهة نظرك لا تزال قائمة.
هناك شخص ما في فريق البنية التحتية لدينا يتفق بشدة مع هذه العبارة، فهو يشارك سير عمل وتوجهًا مشابهًا لك :ضحك:
هذا عادل بما فيه الكفاية، ربما سأعيد تقديم معرف الموضوع أيضًا، نظرًا لأن outbound_message_id يتم تعيينه بالفعل مرة واحدة ولا يتغير (بناءً على ما إذا كان المنشور تم إنشاؤه في واجهة مستخدم Discourse على الويب أو عبر بريد إلكتروني وارد).
ربما لن أحتاج إلى هذا الآن لأنني أضيف معرف الموضوع إلى Message-ID مرة أخرى.
أنا لست متأكدًا حقًا من هذا، لدي شعور بأننا لا نريد حقًا معرف الموضوع في معرفات الرسائل هذه، مجرد وجود معرف المنشور يجعله بسيطًا للغاية. سأجرب هذا بدلاً من ذلك:
لا مشكلة لدي. لقد وجدت صعوبة خاصة في ربط رؤوس رسائل البريد الإلكتروني بالمنشورات لأن post.id غير واضح في واجهة المستخدم أو عنوان URL للمنشور المحدد على الويب. وجود ذلك في رأس سياق إضافي سيكون جيدًا بنفس القدر.
مرحباً كاميرون، لقد كنت في لقاء شركتنا ثم في إجازة خلال الأسبوعين الماضيين، وأعود إلى الأمور اليوم. إذا لم يتم دمجه هذا الأسبوع، فسيتم بالتأكيد دمجه الأسبوع المقبل. أعتذر عن التأخير!
بواسطة مارتن برينان عبر Discourse Meta في 20 سبتمبر 2022 00:17:
مرحباً كاميرون، لقد كنت في لقاء شركتنا ثم في إجازة لمدة أسبوعين
الأسبوعين الماضيين، وأنا أعود إلى الأمور اليوم. إذا لم يتم
دمجها هذا الأسبوع، فسيتم بالتأكيد دمجها الأسبوع المقبل.
اعتذارات عن التأخير!
لا داعي للاعتذار. كنت أعرف أنك كنت بعيدًا، ولم أكن متأكدًا من توقيتك أو عودتك. وأعتقد أنه قد لا يزال يوم الاثنين حيث أنت
).
