المنشور الثاني الذي حدث فيه هذا كان على Messages section for sidebar - #13 by nathank. كان الأمر مشابهًا: لم يضف التعديل أي شيء من شأنه أن يؤدي إلى إشعار - كان الاقتباسان موجودين من قبل - ومع ذلك تم إعلامي مرة ثانية.
فيما يلي خطوات إعادة الإنتاج التي وجدتها والتي نجحت [1]
أنت بحاجة إلى 3 مستخدمين: OP، notifiedUser، spammer
ينشئ OP موضوعًا
يرد notifiedUser
يرد OP على منشور notifiedUser يتم إخطار notifiedUser بالرد (متوقع)
يرد spammer على منشور notifiedUser. يحتوي الرد على رابط لمنشور آخر بواسطة notifiedUser واقتباس من المنشور الذي ترد عليه. (اختياري: يمكنك أيضًا @الإشارة إلى notifiedUser) يتم إخطار notifiedUser بالرد (متوقع) [في حال أضفت @إشارة، يكون الإشعار بخصوص @الإشارة (متوقع)]
يقرأ notifiedUser الردود الجديدة لوضع علامة على الإشعارات كـ مقروءة ويتنقل إلى مكان آخر حتى لا نفوت أي إشعار.
يقوم spammer بتعديل الرد لإصلاح خطأ مطبعي (أو يضيف edit1) يتم إخطار notifiedUser بالاقتباس (غير متوقع، لقد تم إخطاره بهذا الرد من قبل وكان الاقتباس موجودًا من قبل، لا حاجة لإخباره)
يقوم spammer بتعديل الرد مرة أخرى لإصلاح خطأ مطبعي آخر (أو يضيف edit2) يتم إخطار notifiedUser بالارتباط (غير متوقع، لقد تم إخطاره بهذا الرد من قبل وكان الرابط موجودًا من قبل، لا حاجة لإخباره)
يعرض الفيديو الخطوات النهائية 5-7 فقط. spammer على اليسار، notifiedUser على اليمين
على الأقل في معظم الأوقات، وفي بعض الأحيان لا يؤدي حتى إضافة @إشارة في التعديل إلى إطلاق إشعار جديد ↩︎
غيّر الأسطر 589-599 من:
# قد يتم كبت الإشعارات المرتبطة، أو المقتبسة، أو المذكورة، أو المقتبسة في الدردشة إذا كان لديك بالفعل إشعار رد
if [
Notification.types[:quoted],
Notification.types[:linked],
Notification.types[:mentioned],
Notification.types[:chat_quoted],
].include?(type)
if existing_notifications.find { |n| n.notification_type == Notification.types[:replied] }
return
end
end
إلى:
# قد يتم كبت الإشعارات المرتبطة، أو المقتبسة، أو المذكورة، أو المقتبسة في الدردشة إذا كان لديك بالفعل أي إشعار حول هذا
# المنشور
if [
Notification.types[:quoted],
Notification.types[:linked],
Notification.types[:mentioned],
Notification.types[:chat_quoted],
].include?(type)
return if existing_notifications.any?
end
هذا سيعمل ولكني قلق بعض الشيء لأنه قد تتسرب إشعارات أخرى هنا. (إشعارات الإضافات (plugins) على سبيل المثال والتي قد نرغب في كبتها)
@lindsey هناك سؤال يتعلق بالمنتج هنا، متى يجب علينا كبت إشعار؟
لست متأكداً. أليس هذا إشعار رد في الفيديو الخاص بي؟ ومع ذلك، لا يزال هناك إشعار حول الاقتباس والرابط بعد ذلك. لذا، فإن تمديد ذلك لأنواع الإشعارات الأخرى قد لا يساعد هنا. ولكن ربما يغطي حالات حافة أخرى.
أتساءل عما إذا كانت المشكلة في طريقة إعادة إنتاجي هي إشعار “ردان”. هل يكسر ذلك التحقق من الإشعارات الموجودة بواسطة هذا الرد عند تعديل الرد؟
بشكل عام، أتوقع عدم وجود إشعار إضافي بسبب التعديل إذا كانت جميع المشغلات موجودة بالفعل في المنشور عندما قرأته من قبل. لا ينبغي أن يؤدي إصلاح خطأ مطبعي غير متعلق بالإشارة/الرابط/الاقتباس إلى إشعار جديد.
أعتقد أنه في حالة استبدال المشغل، أفضل أن يتم تغيير الإشعار غير المقروء الحالي (أو استبداله) بدلاً من تلقي إشعار ثانٍ. لا ينبغي أن يؤدي إزالة الإشارة @ في منشور المستخدم لتجنب الضوضاء إلى إشعار ثانٍ حول الاقتباس. أتوقع أن يختفي الإشعار الخاص بالإشارة @.
أعتقد أن الحالة الوحيدة التي أرغب فيها في الحصول على إشعار جديد هي إذا أضاف التعديل نوع إشعار أكثر أهمية. لذلك، عندما يربط شخص ما منشوري ثم يضيف تعديلاً يشير إليّ @، فمن المنطقي إخباري لأنهم لم يعودوا يتحدثون عن شيء كتبته ولكن مباشرة إليّ. نظرًا لأن التعديل لم يعد يرفع الموضوع، فقد تكون الإشارات @ طريقة مفيدة لتنبيه المستخدمين بشأن التعديلات.
أعتقد أن موين يصف الوضع المثالي من منظور المستخدم، ولكني أعتقد أننا سنواجه صعوبة في تحقيق هذا الجزء بشكل صحيح:
ربما يمكننا إدارة ذلك للإشعارات داخل التطبيق، لكن لا يمكننا إلغاء إرسال إشعارات الدفع (push notifications) أو إشعارات البريد الإلكتروني. (بشكل عام، أنا متردد في إضافة المزيد من التعقيد إلى الإشعارات، لذا في حين أن البعض قد يوافق على أن يكون الإشعار داخل التطبيق والبريد الإلكتروني/الدفع مختلفين، فأنا أفضل أن نتخلى عن هذا.)
ومع ذلك، أتفق مع هذا:
إذا كان من المفترض أن يُعلِم منشور مستخدمًا ما (على سبيل المثال، مؤلف المنشور يقتبس المستخدم أ)، قم بإعلام المستخدم (المستخدمين) المعنيين (على سبيل المثال، يتلقى المستخدم أ إشعارًا بأنه تم اقتباسه).
إذا كان التعديل على هذا المنشور لا يغير من يجب إعلامه أو سبب إعلامه (على سبيل المثال، يقوم مؤلف المنشور بتعديل خطأ مطبعي)، فلا تقم بإعلام أي شخص.
إذا كان التعديل على هذا المنشور يغير من يجب إعلامه (على سبيل المثال، يذكر مؤلف المنشور المستخدم ب) أو السبب (على سبيل المثال، يذكر مؤلف المنشور المستخدم أ)، قم بإعلام المستخدم (المستخدمين) المتأثرين (على سبيل المثال، يتلقى المستخدم ب إشعارًا بالإشارة، ويتلقى المستخدم أ إشعارًا بالإشارة).
ترغب @lindsey في الحصول على إشعارات جديدة للمعلومات الجديدة التي تم تحريرها في المنشور…
المواءمة الكاملة هنا تتطلب تتبعًا معقدًا للغاية… أنا أقيّم حجم التغيير، ولكن بصراحة، عدم القيام بأي شيء في الوقت الحالي هو الأسهل على الأرجح، لأن التغيير سينتهي به الأمر إلى أن يكون هشًا للغاية.
استخراج الإشارات الجديدة والقديمة هو شيء سيتطلب إما محللًا (لا نقوم بالتحليل في تلك المرحلة) أو تعبيرًا نمطيًا هشًا (regex).
نقل هذا إلى ميزة @Moin وإغلاق طلب السحب الخاص بي في الوقت الحالي.
أولاً وقبل كل شيء، لا أريد تلقي إشعار آخر إذا لم يتغير شيء في المنشور يسبب إشعارًا. تصحيح خطأ مطبعي لا ينبغي أن يرسل لي إشعارًا إذا كنت قد تلقيت إشعارًا بالفعل لمجرد أنه تم دمج إشعارين حول نفس الموضوع سابقًا. ولم ألاحظ هذا لسنوات حتى حدث في ديسمبر.
لقد طلبت من ChatGPT كتابة ملخص لما قاله لي حول هذه المشكلة، عندما حاولت العثور على خطوات إعادة الإنتاج بناءً على التعليمات البرمجية
ملخص: لماذا يتم منع الإشعارات المكررة، ولماذا تفشل هناالذكاء الاصطناعي
المشكلة الأساسية
يعتمد منع التكرار على العثور على إشعار رد لا يزال مرتبطًا بالمنشور الذي تم تحريره، ولكن إشعارات الرد يتم دمجها أو إتلافها أو إعادة إرفاقها بمنشور مختلف.
ونتيجة لذلك، لا يمكن لكبت وقت التحرير اكتشاف أن المستخدم قد تم إخطاره بالفعل بالرد بشكل موثوق.
يتم منع الإشعارات المكررة في PostAlerter عن طريق:
تتبع المستخدمين الذين تم إخطارهم بالفعل أثناء إنشاء المنشور
notified = []
كبت المشغلات الثانوية إذا كان إشعار الرد موجودًا
if [:quoted, :linked, :mentioned, :chat_quoted].include?(type)
return if existing_notifications.find { |n|
n.notification_type == Notification.types[:replied]
}
end
يهدف هذا إلى تجنب إخطار المستخدم مرتين حول نفس المنشور.
دمج إشعارات الرد
يتم دمج إشعارات الرد (:replied) لكل موضوع:
بحيث لم يعد الإشعار يمثل المنشور الذي أدى إلى تشغيله في الأصل. ونتيجة لذلك، فإن منطق الكبت الذي يعتمد على مطابقة post_number لا يمكنه اكتشاف الإخطارات السابقة للمنشورات التي تم تحريرها بشكل موثوق.
لماذا يفشل هذا في حالة إعادة الإنتاج
في حالة إعادة الإنتاج:
يتم إخطار المستخدم بالرد في البداية
عند وجود عدة ردود، يتم دمج إشعارات الرد
الإشعار المدمج:
قد لا يعود موجودًا للمنشور الذي تم تحريره، أو
موجود بـ post_number مختلف
عند التحرير:
منطق الرد لا يعمل (new_record == false)
فحوصات الكبت تبحث فقط عن إشعار :replied مرتبط بالمنشور
لم يتم العثور على أي شيء ← يفشل الكبت
يتم تشغيل اكتشاف الاقتباس/الرابط مرة أخرى وينشئ إشعارات جديدة
عندما أنشئ موضوعًا وأذكر فيه مستخدم الاختبار الخاص بي في فئة عامة ثم أنقله إلى فئة خاصة بعد بضع دقائق، تتم إزالة الإشعار أيضًا من الواجهة - على الرغم من أنه تلقى بريدًا إلكترونيًا بخصوص الإشارة (@mention).
لذلك، فإن الإشعارات داخل التطبيق التي يتم حذفها، على الرغم من إرسال بريد إلكتروني، موجودة بالفعل.
لا يزال الأمر يبدو وكأنه خطأ أنه عندما يضيف mcwumbly علامة إلى موضوعه، أتلقى إشعارًا جديدًا بأنه تم ربط منشوري. كان الرابط موجودًا بالفعل عندما نشر الموضوع، وتم إعلامي بالاقتباس. لم يتغير شيء سوى العلامة. فلماذا يُتوقع أن يؤدي التعديل إلى إطلاق إشعار ثانٍ؟
بالإضافة إلى الخطوات المذكورة في المنشور الأول، يحدث هذا أيضًا مع الخطوات التالية:
١. ينشئ المستخدم الذي تم إخطاره موضوعًا
٢. يرد مرسل الرسائل غير المرغوب فيها كموضوع مرتبط. يحتوي المنشور على رابط بشكل افتراضي، لذا تحتاج فقط إلى إضافة الإشارة إلى المستخدم (@mention) والاقتباس.
يتم إخطار المستخدم الذي تم إخطاره بالإشارة (@mention) (متوقع) ويقرأ الموضوع
٣. يضيف مرسل الرسائل غير المرغوب فيها علامة إلى الموضوع
يتم إخطار المستخدم الذي تم إخطاره بأنه تم اقتباسه في المنشور (غير متوقع، لقد تم إخطاره بالفعل ولم يتغير شيء)
٤. يقوم مرسل الرسائل غير المرغوب فيها بتعديل عنوان الموضوع
يتم إخطار المستخدم الذي تم إخطاره بأنه تم ربطه في المنشور (غير متوقع، لقد تم إخطاره من قبل، ولا يزال المنشور لم يتغير)
