عناوين لـ إشعارات البريد الإلكتروني حتى يتمكن مستخدمو Gmail من التصفية حسب العلامات؟

ساهم ميزة
,
1

تم إغلاق المنشور باعتباره تكرارًا بريد إلكتروني: يجب أن تحتوي رؤوس البريد على علامات، ربما في إشارة إلى https://meta.discourse.org/t/customs-email-headers-and-or-subjects-tags/16873، لكن الأخير عام إلى حد ما، وأود مناقشة مشكلة محددة لدينا:

نحن نستخدم العلامات كبديل منطقي لعشرات القوائم البريدية حول مواضيع فرعية مختلفة للمشروع. بدأنا في استخدام الفئات، لكن ذلك أصبح غير عملي - الفئات ثقيلة، ولا تسمح بالنشر المتقاطع بسهولة، ولأسباب أخرى تمامًا، نعتقد أن العلامات هي الأنسب. [1]

ومع ذلك… هناك مشكلة. بينما من الممكن وضع %{optional_tags} في القالب لإشعارات البريد الإلكتروني، فإن تصفية Gmail المحدودة للغاية لا تفعل شيئًا ذكيًا بهذا - وحتى بالنسبة لمستخدم البريد التقليدي، فإن كتابة قاعدة procmail التي تفكك سطر الموضوع وتحلله أمر مزعج إلى حد ما.

لذلك، سيكون من الجيد وجود العلامة في مكان آخر. بالنسبة لأشخاص procmail، سيكون رأس X-Tags مخصصًا كافيًا، لكن Gmail لن يهتم، لذا نحتاج إلى شيء آخر.

إحدى الأفكار هي استخدام العلامات فعليًا كـ List-ID، لكن لست متأكدًا مما إذا كان Gmail يفعل الشيء الصحيح مع علامات List-ID المتعددة لا يُسمح بحقول List-ID المتعددة [2]. فكرة أخرى، وهي غريبة بعض الشيء ولكن أعتقد أنها ستنجح: وضع tag@subdomain.example.org (وربما أيضًا tag2@subdomain.example.org، tag3@subdomain.example.org، …) في قائمة النسخة الكربونية (CC). يمكن لـ Google التصفية بناءً على هذا، ومعظم الأنظمة الأخرى لديها أيضًا ميزات متقدمة بشكل معقول للتعامل مع النسخة الكربونية (CC) كميدان متعدد القيم. وسنقوم بإعادة توجيه أي بريد يتم إرساله فعليًا إلى هذه العناوين إلى العدم [3].

كميزة إضافية، يمكن استخدام نهج النسخة الكربونية (CC) كوسيلة لإضافة علامات على البريد الوارد (انظر Add tags by email). مرة أخرى، غريب بعض الشيء، ولكن بعد ذلك، كل البريد الإلكتروني غريب بعض الشيء، في عام 2022.

  1. إذا كنت ترغب في مناقشة هذا، يمكنني… في موضوع آخر! ↩︎

  2. تبًا لك، RFCE 2919! ↩︎

  3. أي /dev/null ↩︎

إعجابَين (2)
2

أنا منفتح على أي اقتراحات أو أفكار أخرى لدى أي شخص. لا يمكننا اقتراح نقلة واسعة النطاق إلى Discourse بشكل معقول بدون هذا.

3

وأيضًا، لماذا لا توجد علامات # هنا؟ :slight_smile:

4

قد يبدو أنها ستعمل، لكنك ستحتاج إلى إضافة مخصصة.

5

ما هي حالة الاستخدام الخاصة بك بالضبط؟

أود أن أتعرف على سبب شعورك بالحاجة إلى مساعدة الأشخاص في تصفية إشعارات البريد الإلكتروني من موقعك. الاستخدام المقصود لـ Discourse هو أن أعضاء المجتمع يستخدمون ببساطة إشعارات البريد الإلكتروني ليتم إبلاغهم عند وجود نشاط يهتمون به وينقرون على الرابط لتسجيل الدخول عندما يرغبون في المشاركة في المناقشات. بالنسبة للمواقع التي ترغب في ذلك، يمكن تمكين الرد عبر البريد الإلكتروني. ولكن لا يزال يتعين على العضو أن يعتاد على تسجيل الدخول لمواصلة المناقشة على الموقع.

بهذه الطريقة يستفيد الجميع ويمكنهم المساهمة في الجهد التعاوني لتنظيم وإدارة المناقشات على الموقع. ولن ينتهي بك الأمر بمجموعة من المناقشات القديمة المعزولة في مجلدات البريد الإلكتروني للجميع. عندما يتم استخدام Discourse كما هو مقصود، يمكن ببساطة حذف الإشعارات المستلمة عبر البريد الإلكتروني.

البريد الإلكتروني أيضًا صعب جدًا في التعامل معه، وليس فقط لـ Discourse. كلما زاد عدد أفراد مجتمعك الذين يسجلون الدخول ويتفاعلون على موقعك، زاد نجاح مجتمعك (وسهولة إدارته).

ربما لم يكن Discourse هو الخيار الصحيح لمجتمعك، أو قد تحتاج إلى الاحتفاظ ببضعة قوائم بريدية قيد التشغيل أثناء بناء موقع Discourse الخاص بك؟ أعرف أنه قد يكون من الصعب تغيير عادات المجتمعات القديمة.

حظا سعيدا! :sunflower:

إعجابَين (2)
6

أعتقد أن هذا قد يكون صحيحًا.

هل ما زال لديك مستخدمون لـ procmail؟ ومستخدمون لـ Gmail، ومستخدمون لـ Discourse؟ إرضاء جميع هذه المجموعات الثلاث سيكون صعبًا للغاية بالفعل.

إذا كانت ميزانيتك تتراوح بين 2000 و 5000 دولار، فقد تحصل على إضافة مخصصة تقوم بما تطلبه، ولكن من الصعب تخيل أنها ستكون مرضية لأي شخص. أنت لا تعرف المشكلات الأخرى التي ستنشأ بمجرد حل المشكلات التي تعرفها الآن. أذكر نفسي بإدارة قوائم البريد عندما استخدمت مجموعة من الأشخاص بوابات بريد إلكتروني تعتمد على الشبكة المحلية ولم تتبع RFC-822 (كان ذلك عندما استخدمت procmail و emacs rmail). المشكلة ببساطة لا يمكن حلها.

أوصي بالذهاب مع الفئات فقط. أو، إذا كنت تريد حقًا قوائم بريد تتبع اصطلاحات عقدين من الزمن مضت، فالتزم بما يعمل.

إعجابَين (2)
7

إذا كانت هذه الميزات موجودة بالفعل في منصات أخرى متجذرة في نموذج القائمة البريدية التقليدي، فمن المحتمل أن تحقق نجاحًا أكبر هناك، بدلاً من طلب إضافتها إلى منتج يواجه المستقبل.

أو، بعبارة أخرى، إذا كان هذا الأمر حاسمًا، فلماذا تفكر في Discourse في المقام الأول؟ هل يمكن توسيع HyperKitty لإضافة الوظائف التي تحتاجها؟

إعجاب واحد (1)
8

الهدف

حاليًا، لدى Fedora مئات القوائم البريدية، مع حوالي 90 منها بدرجة ما من النشاط، وعدد قليل منها نشط للغاية. أريد توحيد كل ذلك في مكان واحد، والذي يتضمن إنجاح مجتمع المساهمين لدينا. إذا كان هناك خيار أفضل من Discourse لهذا الغرض، فلم ينشئه أحد بعد.

نسخة مختصرة

لقد كنت أعمل بنشاط على هذا لمدة ثلاث سنوات وأفكر فيه لمدة عشر سنوات على الأقل. في التحدث إلى الأشخاص في مجتمعي حول ما يعيقهم، ظهر هذا الأمر المحدد بشكل متكرر.

نسخة طويلة:

في نفس الوقت تقريبًا الذي بدأ فيه Discourse[1]، أنشأنا واجهة أمامية رسومية لـ Mailman3 تسمى Hyperkitty، تهدف إلى أن تكون واجهة ويب حديثة يمكن للأشخاص استخدامها للوصول إلى القوائم البريدية الأساسية. يمكنك رؤية هذا قيد التنفيذ في قائمة Fedora Devel.

يحتوي Hyperkitty على بعض الأفكار الرائعة، ولكنه لم يتم تمويله حقًا على النطاق اللازم للنجاح، وانتهى به الأمر بإطلاقه بالتصميم الأولي وبدون توفير لتحسينه وإصلاحه في الاستخدام الفعلي. كما أنه يأخذ البريد الإلكتروني كأساس تحته، وهذا قيد الأمور حقًا[2] - حتى لو كانت لدينا الموارد، فإن الالتزام بهذا كأكبر عامل مشترك[3] كان سيشكل حدًا محبطًا.

لذلك أفهم أين أنت في هذا الأمر. إذا قمت برحلة عبر آلة الزمن إلى تاريخ discourse.org يمكنك أن ترى[4] أن Discourse اعتمد بشكل كبير على الدروس المستفادة من كل من المنتديات والقوائم البريدية واستبدالهما كليهما…

2013

… وهذا ما نجا إلى حد كبير حتى اليوم، على الرغم من وجود حديث أقل آخر حول القوائم البريدية في الصفحات المختلفة. لقد مررت بنفس الشيء الذي كنا سنمر به لو كانت لدينا الموارد للاستثمار في Hyperkitty - مشكلة البريد الإلكتروني كأدنى خط أساسي - وتوصلت إلى الاستنتاج المنطقي. أنا أتفهم تمامًا من أين أتيت بقولك صراحة الآن أن جلب الأشخاص إلى الموقع هو الاستخدام الصحيح.

حاليًا:

  • لدينا عشرات القوائم البريدية النشطة
    • مع مئات المشاركين النشطين
    • وآلاف المشتركين السلبيين.
  • تعود هذه القوائم إلى أكثر من 20 عامًا حرفيًا.
  • العديد من الأشخاص القدامى في المصادر المفتوحة متعلقون حقًا بهذه الطريقة في العمل.
    • إنها مألوفة،
    • تم إعدادها بالفعل، و
    • تصل إلى روتين يومي دون الحاجة إلى إضافة “تحقق من موقع ما”
  • العديد من الأشخاص نشطون في أجزاء مختلفة من المشروع، ولكن هذه “البصمة” فردية للغاية

لكن:

أولاً. هذه القوائم أقل وظيفية مما يعتقد الكثيرون أنها كذلك:

  • الإشراف شبه مستحيل (عصا كبيرة شاملة أو لا شيء على أفضل تقدير)
    • على الرغم من الجهود، لا يلتزم الأشخاص دائمًا بالمعايير التي نتوقعها
  • الخيوط الضخمة ليست مناقشة جيدة
  • المضايقات خارج القائمة سهلة الإطلاق وخارجة عن سيطرتنا
  • إعادة النشر المتعدد فوضى، حيث الاشتراكات ليست متسقة
  • من المستحيل مواكبتها إلا إذا كنت ملتزمًا
  • الأشخاص الذين يجب أن يشاركوا لا يشاركون لمزيج مختلف من الأسباب المذكورة أعلاه

ثانياً. البريد الإلكتروني ليس المستقبل

  • القوائم البريدية غير واضحة إلى حد كبير لمحركات البحث ولا تبدو كـ “نشاط حقيقي” لمعظم العالم
  • الأشخاص الجدد لا يرغبون في الاشتراك في القوائم البريدية.[5]
  • “ثقافة” القوائم البريدية ليست شيئًا حقيقيًا بعد الآن.[6]
    • وواجهة الويب الخاصة بـ Gmail معادية بنشاط للاتفاقيات التقليدية مثل الردود المضمنة.

ثالثاً. البريد الإلكتروني بشكل عام محكوم عليه بالفشل

  • لدى مقدمي الخدمات الكبار القدرة على “حل” البريد العشوائي لأنفسهم، ولديهم الآن حافز سلبي لحله عالميًا.
  • لدى مقدمي الخدمات الصغار فرصة متناقصة للتسليم بشكل موثوق.
  • تقوم القوائم البريدية بإعادة النشر بطبيعتها، ولا يهتم كل البنية التحتية للتوقيع والتحقق حقًا.
  • تتحول الشركات إلى Slack وما شابه ذلك للتواصل الوظيفي، تاركة البريد الإلكتروني للإعلانات والبث.
    • و Jira و github وما إلى ذلك للتفاعلات التي تركز على سير العمل.
  • مرة أخرى، “الأشخاص العاديون” لا يستخدمونه لأي شيء سوى تلقي إشعارات حول مختلف الشركات التي هم عملاء لها. إنه ليس حقًا للاتصال الشخصي بعد الآن.

لكن لا تزال هناك حاجة

لدينا محادثة في الوقت الفعلي مغطاة[7]، ولكن لا يزال يتعين علينا إجراء محادثات طويلة وغير متزامنة قدمتها القوائم البريدية. الدردشة لا تغطي كل شيء، ولا تعمل بشكل جيد عالميًا ومع المتطوعين ذوي الالتزامات الزمنية المتفاوتة. وأدوات سير العمل ضيقة للغاية.

Discourse هو حقًا الخيار الأفضل

  • القوائم البريدية ليست مستقبلًا قابلاً للتطبيق.

  • Hyperkitty عالق في عام 2014.

  • لدينا الكثير لاستخدامه فقط Github / Gitlab.

  • الاحتمالات الأخرى لا تكفي:

    • Ponymail يعاني من نفس مشكلة البريد الإلكتروني كأدنى خط أساسي
    • Vanilla ليس جيدًا. سأترك ذلك هناك. :slight_smile:
    • Google Groups هو أسوأ ما في كل شيء.

  • على الجانب الإيجابي لـ Discourse: تتوحد العديد من مجتمعات المصادر المفتوحة الأخرى حوله. أبرزها: Python، GNOME…

إدخال كاساندرا

ليس قاعدة البيانات - أعني، إخبار الناس بالهلاك ولكن لا أحد يصدق. أسمع الكثير من “البريد الإلكتروني يعمل بشكل جيد”، و “لا أرى مشكلة في القوائم البريدية”، وبالطبع، “أكره المنتديات”، أو حتى على وجه التحديد “لا أحب Discourse”.

لكننا نحتاج حقًا إلى التغيير.

إذًا…

أحتاج إلى جعل مجتمع كبير ونشط ومهم من المصادر المفتوحة ينقل منصة اتصالات مشروعه الأساسية إلى Discourse، والكثير من الناس متشككون. إنه تغيير كبير. أريد جعل ذلك سهلاً قدر الإمكان، سواء لجعل الأمر أسهل وألطف للأشخاص المتشككين ولكن المستعدين للمحاولة، ولجعل المحاولة ممكنة للأشخاص الذين لديهم تفاعل عبر البريد الإلكتروني - بما في ذلك التصفية - كعائق شخصي.

أعتقد أنه بمجرد وصولهم إلى هناك، سيقوم العديد من الأشخاص بتعديل سلوكياتهم - سيجد المزيد من الأشخاص أن التفاعل المباشر مع الموقع ليس سيئًا للغاية.[8] ولدينا نظام إشعارات خاص بالمشروع بأكمله لدي خطط لربطه، ونأمل أن يتمكن ذلك في النهاية من منح الأشخاص المزيد مما يحتاجونه حقًا.

ولكن في هذه الأثناء، أنا بحاجة إلى منح الأشخاص ما يطلبونه.

  1. لقد حاولت بالفعل اقتراح Discourse كنهج بديل في ذلك الوقت، بدلاً من إنشاء نهجنا الخاص. لو كان لدي آلة زمن، ربما أعود وأدفع ذلك بقوة أكبر. لكنني لم أكن في منصبي الحالي في ذلك الوقت وكان القرار قد اتخذ بالفعل… ↩︎

  2. درس مماثل من LUGNET، أعتقد أن برنامج المنتدى الأكثر روعة ومنطقية في التسعينيات - ولكنه مرتبط بـ NNTP كواجهة خلفية. ↩︎

  3. أعرف أن المصطلح هو “أقل قاسم مشترك” ولكن هذا لا معنى له. مثل “أستطيع أن أهتم أقل”، ولكن الآن أيضًا مع الرياضيات. ↩︎

  4. أعني، إذا كنت لا تتذكر بالفعل، بالطبع! ↩︎

  5. في كوريا، البريد الإلكتروني لكبار السن جاء إلينا جميعًا! ↩︎

  6. لا أستطيع تذكر آخر مرة سمعت فيها شخصًا يقول “آداب الشبكة”. ↩︎

  7. باستخدام Matrix، على https://chat.fedoraproject.org/… ↩︎

  8. على الرغم من ذلك، لدينا بالتأكيد هذا الشخص، لذلك لن يكون الجميع. ↩︎

5 إعجابات
10

كتابة رائعة! :ok_hand:

هل يمكنك وصف التصفية التي تتحدث عنها بمزيد من التفصيل والتي يعتمد عليها الناس في بريدهم الإلكتروني؟ لقد كنت هنا لفترة طويلة وأدرت قوائم mailman بنفسي وشاركت (ولا أزال أشارك) في العديد من القوائم البريدية، لكنني لم أصادف أبدًا تصفية تلقائية باستخدام رؤوس الرسائل. يبدو لي أنه إذا اشترك شخص ما في قائمة ويريد تصفيتها في مجلد في بريده الإلكتروني، فسوف يقوم بإعداد ذلك بنفسه على أساس كل قائمة على حدة. يمكنك القيام بذلك باستخدام discourse أيضًا، أليس كذلك؟

أعتقد أن الفئات تعمل بشكل جيد كبديل للقوائم البريدية، مع تمكين وضع القائمة البريدية بواسطة المستخدم أو مراقبة المستخدم لفئات معينة حتى يتم إرسال بريد إلكتروني إليهم لكل منشور. ربما نحتاج إلى معرفة المزيد أيضًا حول سبب اعتقادك أن تنظيم المناقشات في علامات أفضل وتستحق الجهد لتحقيق التكافؤ مع كيفية عملها مع الفئات بالفعل.

تعديل: أذكر بمنشوري القديم حول هذا الموضوع، من عام 2014! :scream:

إعجاب واحد (1)
11

بالتأكيد. رؤوس الرسائل التي تقوم Discourse حاليًا بتعيينها تبدو كالتالي (من إشعار فعلي من هذا الموضوع):

List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/efed8ca1777379c660afc031464b98eb4e6fa2323a71fa12fa2269eeca5b0905>
X-Discourse-Post-Id: 1216779
X-Discourse-Topic-Id: 249982
X-Auto-Response-Suppress: All
Auto-Submitted: auto-generated
Precedence: list
List-ID: Discourse Meta | feature <feature.meta.discourse.org>
List-Archive: https://meta.discourse.org/t/headers-for-email-notifications-so-that-gmail-users-can-filter-on-tags/249982
Feedback-ID: meta:user_replied:discoursemail

لو لم يكن Gmail موجودًا، فإن إضافة شيء مثل:

X-Discourse-Tags: some-tag, another-tag

انظر Customs email headers and/or subjects tags - #6 by mattdm — إذا تم تمرير إعداد email custom headers عبر توسيع القالب بحيث يعمل X-Discourse-Tags: %{optional_tags}، فإن هذا الجزء سيعمل بالفعل.

وبالنسبة لمستخدمي procmail وعملاء البريد الإلكتروني القدامى الآخرين، سيكون هذا كافيًا. لسوء الحظ، لأسباب جوجل غير المفهومة، لا يمكن لـ Gmail التصفية بناءً على علامات عشوائية، وهو (على حد علمي) يقتصر على To: و From: و Cc: و … لحسن الحظ على الأقل، List-ID. نظرًا لأن هذا هو “الفيل الضخم” (800-lb gorilla)، لاستيعاب هؤلاء المستخدمين، فإن تعيين List-ID حسب العلامة بدلاً من الفئة (أو، بالاشتراك؟) هو أفضل ما يمكنني التفكير فيه.

ومع ذلك، فإن RFC 2919 ينص على أنه لا يُسمح إلا بـ List-ID واحد لكل رسالة. لذا يتبقى لدينا:

  1. اختر علامة واحدة بشكل عشوائي[1]
  2. قم بإنشاء شيء يتضمن جميع العلامات، مثل List-ID: firsttag_secondtag.discourse.example.org ودع المستخدمين يكتشفون ذلك. [2]
  3. قم بإنشاء رسائل بريد إلكتروني متعددة لكل إشعار، واحدة لكل علامة وتختلف فقط في هذا الرأس[3]
  4. اترك List-ID يشير إلى الفئة، وبدلاً من ذلك استخدم فكرة CC… [4]

لا أحب أيًا من هذه الخيارات حقًا. لذا كخطوة أولى، فإن X-Discourse-Tags: سيغطي المستخدمين غير Gmail على الأقل. (وهو ربما تداخل جيد جدًا مع المستخدمين المقاومين للويب، لذلك أعتقد أنه يستحق القيام به لمعرفة إلى أي مدى سيصل بنا ذلك.)

  1. مربك! ↩︎

  2. ليس جيدًا ↩︎

  3. أيضًا ليس جيدًا ↩︎

  4. غير فعال للغاية. مجرد إضافة Cc: %{optional_tags}[4] لن ينجح، لأنه سيحتاج إلى التوسع بحيث تتوافق كل علامة مع عنوان بريد إلكتروني حقيقي (ثقب أسود). ↩︎

3 إعجابات
12

نعم، إلى حد كبير! الفقرة الأخيرة تلخص الأمور بشكل جيد!

إعجابَين (2)
13

أدعم بشدة إضافة X-Discourse-Tags و X-Discourse-Category (للتكافؤ)

أعتقد أنه على المدى الطويل بالنسبة لـ Gmail يمكننا إضافة خيار للمستخدم:

  • يرجى إضافة جميع العلامات التي ينتمي إليها هذا الموضوع في عناوين الموضوعات المرسلة عبر البريد الإلكتروني.

على سبيل المثال، شيء من هذا القبيل:

[Discourse Meta] [feature] [email] [notifications] Header for email notifications

أو ربما عند تمكينه:

[Discourse Meta] Header for email notifications … [feature] [email] [notifications]

5 إعجابات
14

نعم، سيكون ذلك مثيرًا للاهتمام كخيار للمستخدم. لدينا حاليًا هذا على مستوى الموقع:

%{optional_re}%{topic_title} [Fedora] %{optional_pm}%{optional_tags}

لقد تلقينا ردود فعل قوية بأن وضع العلامات في أي مكان آخر غير الأخير كان مزعجًا. وبعض التعليقات بأن جوجل ليست ذكية جدًا في التصفية المفيدة على أسطر الموضوع الجزئية.

لست متأكدًا من مقدار ما يمكننا “إصلاحه” في جوجل، (أو بالأحرى، أنا متأكد تمامًا، وهو “ليس كثيرًا”). لذلك قد يكون هناك قدر معين من “حسنًا” الذي سأضطر إلى إقناع الناس بقبوله.

4 إعجابات
15

هناك بعض الأمور البسيطة التي يمكننا القيام بها لتحسين الوضع.

في الوقت الحالي نحن نقوم بـ

  1. التقييد بـ 3 (ترتيب عشوائي)
  2. عدم وضع العلامات داخل [ ]

أنا متردد ولكن أعتقد أن الحد العشوائي بـ 3 ليس جيدًا، يجب علينا فقط إزالته.

بالإضافة إلى ذلك، سيكون tags.map{|t| \"[#{t}]\"}.join(\" \") أفضل لأن المرشح يمكن أن يكون على [tagname] مقابل tagname الذي من المرجح جدًا أن يظهر في عنوان الرسالة الخاصة.

@martin ما رأيك؟

5 إعجابات
16

هذا منطقي أكثر بمعرفة التاريخ. يبدو أن لديك ميزانية لتنفيذ الأمور، وبعض الأفكار الجيدة للوصول إلى بداية جيدة. أعتقد أنه سيكون الأمر صعبًا، واستيراد كل البيانات سيكون تحديًا. سيظل من الصعب إرضاء كل هؤلاء الأشخاص، وسام مع بعض أفكارك على الأقل، لذا سيتم دمجها في النواة ولن تتعطل في المستقبل كما قد يحدث مع إضافة.

3 إعجابات
17

أتفق معك هنا، على الرغم من أنني أعتقد أنه بدلاً من إزالة الحد بالكامل، يمكننا الاعتماد على إعداد max_tags_per_topic؟ أعتقد أن هذا سيكون أكثر أمانًا.

للأسف، إضافة [] حول العلامات لن يساعد كثيرًا في البحث في Gmail، بصريًا فقط، لأنه من خلال ما أراه (على سبيل المثال، انظر إلى https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character، الوثائق المرتبطة لم تعد موجودة ولكنها لا تزال صالحة) يقوم Gmail بإزالة الأحرف الخاصة عند البحث في الموضوع وأماكن أخرى. حاول البحث عن subject:(\"[support]\") في Gmail، ستحصل على كل شيء يحتوي على support في الموضوع وليس فقط تلك التي تحتوي على أقواس مربعة. هذا أمر غير منطقي من Google للقيام به، فهم شركة بحث (حسنًا، بحث وإعلانات) ولكن لا يوجد شيء يمكننا فعله حيال ذلك.

يجب أن نكون قادرين أيضًا على إضافة X-Discourse-Tags و X-Discourse-Category بسهولة في نفس الوقت في MessageBuilder لأن لدينا بالفعل هذه الخيارات في هذا الوقت، وكما تقول @mattdm هذا يغطي المستخدمين المقاومين للويب بشكل جيد:

هل يمكنني تولي هذا إذا أردت؟

5 إعجابات
21

لقد قمت للتو بدمج هذا @mattdm:

لا يساعد هذا كثيرًا مع Gmail، ولكن هذا يجب أن يساعد على الأقل مستخدمي البريد الإلكتروني المستند إلى الطرفية حتى يتمكنوا من تصفية هذه الرسائل بسهولة أكبر.

6 إعجابات
22

ملاحظة @mattdm لقد حاولنا حقًا هنا، ولكن Gmail صعب للغاية. إنه يزيل الكثير من النص عند الترميز، ويداك مقيدتان بشدة.

الحل الوحيد الذي يمكنني التفكير فيه هو جعل أسماء العلامات قبيحة للغاية في رسائل البريد الإلكتروني:

“هذا موضوع تجريبي. [Temail, Tnotifications]” (البادئة T أو أي تسلسل أبجدي آخر “يحبه” Gmail)

لكنه حل قبيح وغير بديهي إلى حد ما.

3 إعجابات
23

شكراً سام (وللجميع!).
أنا أقدر كل الجهود المبذولة في هذا. في النهاية، هناك فقط الكثير من القتال ضد خيارات جوجل الغامضة التي يمكننا القيام بها.

نعم، بجدية. الشيء الوحيد الذي يمكنني التفكير فيه للقيام به أكثر هو إضافة خيار لكل مستخدم:

اجعل سطور موضوع إشعارات البريد الإلكتروني تحتوي على أسماء العلامات بتنسيق قبيح للغاية يمكن لـ Gmail تصفيته.

:-/

5 إعجابات