It doesn’t disable the digest but it does provide another option.
Exactly! If you’re limiting what goes out in the summary, it now becomes a digest. Which is the default setup in Discourse.
It doesn’t disable the digest but it does provide another option.
Exactly! If you’re limiting what goes out in the summary, it now becomes a digest. Which is the default setup in Discourse.
hi @joebuhlig and @pfaffman,
thanks for your replies. but i don’t really get it and maybe you can help me out:
what settings would I need to change to change the current behaviour (ALL topics are included in the daily summary even if the reached the user already during the day because the watch the category)?
thanks in advance,
etienne
If I understand correctly, all you need to do is turn off the mailing-list-mode-daily-summary plugin.
The thiing is that the summary might not include ALL of the posts for the day, it chooses just the top 5 or something. You can see what the normal summary looks like at (something like) /admin -> email -> summary.
ah - now i get what you are telling me.
as we need ALL messages to get to our users in the daily summary using the build-in function is not an option. it does not send out all messages.
thats why we are using the mailing-list-mode-daily-summary plugin in the first place.
but now we are getting comments from users about getting messages twice: first as mail during the day because they are watching a topic and then later in the mlm-daily-summary again.
but probably it is not consistent with the idea of a daily SUMMARY to exclude certain messages (that have been send to the user already). so users have to get used to getting things twice i guess.
If your users watch the categories that they want they will get all of the messages. They do get each one individually rather than a single message with all of them.
People who watch a category or visit the site regularly don’t need mailing list mode or the plugin.
Sounds like you have a conflict between the staff’s desires and the users’ desires. Staff wants everyone to see everything, but the users only want to see a summary.
I’m guessing you’ll need to rectify that discrepancy first.
yes, you are right @joebuhlig. we’ll decide on that in the team.
as for your proposal of paying 200$ for the bugfixes: we are discussing that tomorrow in a team-meeting. will let you know.
hi @joebuhlig,
sorry - i forgot to tell you earlier: i couldnt bet through with my proposal of paying you guys for fixing the bug. so we would wait for you and your team to find time to fix it.
we are looking forward to seeing the bug fixed.
best, etienne
مرحبًا @joebuhlig والآخرين الذين يستخدمون هذه الإضافة — هل يواجه أي شخص آخر مشاكل مع هذه الإضافة منذ إصدار discourse 2.3.0؟ عندما قام مُضيفنا بالترقية إلى الإصدار 2.3.0 قبل بضعة أسابيع، توقفت رسائل البريد الإلكتروني اليومية عن الإرسال. كما أنه عندما أزور شاشة تفضيلات البريد الإلكتروني للمستخدم، فإن مربع الاختيار الخاص بخيار البريد الإلكتروني هذا يرفض الحفظ. يمكنك النقر عليه ثم حفظ، لكن عند إعادة التحميل، يكون غير محدّد. فقط فضولياً لمعرفة ما إذا كان أي شخص قد وجد حلاً لهذه المشاكل. شكرًا جزيلاً إذا كان لدى أي شخص أي رؤى!
مرحبًا ليها، راجع منشوري السابق في 29 يناير وتحقق مما إذا كانت مشكلتك قد تكون مرتبطة أيضًا بإدخال في user_custom_fields؟ تحياتي، إتيان
لدينا بعض التحديثات، وسنود جدًا سماع آراء أي شخص آخر يستخدم هذه الإضافة حول كيفية عملها حاليًا. لدينا مئات المشتركين في رسائل البريد الإلكتروني اليومية، لذا نحن متفائلون بأننا سنتمكن من إعادة عمل هذه الإضافة.
@etienne، شكرًا لمشاركتك نتائجك حول القيم true/false (t/f). لقد قام شخص ما بفحص الأمر، وقال إن الكود يبدو أنه يتعامل مع ذلك بشكل صحيح. لذا، في حالتنا، ما زلتُ مرتبكًا بشأن سبب عدم تلقي بعض المستخدمين لرسائل البريد الإلكتروني اليومية، بينما يتلقاها البعض الآخر فقط كل بضعة أيام. لدينا بالتأكيد مواضيع ومنشورات جديدة كل يوم، لذا يجب أن تُرسل هذه الرسالة يوميًا.
تمكن مطور ووردبريس لدينا (الذي ليس خبيرًا في discourse أو ruby بالمعنى الدقيق، بل هو شخص كان مستعدًا فقط للنظر في المشكلة) من حل خطأ JavaScript في واجهة المستخدم الذي كان يسبب مشكلة في عدم حفظ مربع الاختيار.
أمر آخر أود معرفة رأيكم فيه، أيها المستخدمون لهذه الإضافة: هل تشكون من وجود أي مشاكل قد تتسبب في تعطل هذه الإضافة وقفل الجداول بطريقة إشكالية؟ لدينا مشكلة غامضة أخرى في المنتدى، وإحدى النظريات هي أن هذه الإضافة قد تكون السبب بسبب قفل جداول لا يتم فتحها، لكننا لم نتمكن بعد من التأكد من ذلك.
مرحبًا بكم،
لقد قمت بتحديث Discourse إلى الإصدار 2.4.0 بيتا 2. ومنذ ذلك الحين، تعطلت هذه الإضافة.
حاليًا، يظهر كود الخطأ في Sidekick على النحو التالي:
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined methodapply_notification_styles’ for #UserNotifications:0x00007f1437382668`
آمل أن يتم إصلاح هذه الإضافة قريبًا.
نحن نلاحظ هذا أيضًا.
على الأرجح لأننا نوحّد جميع تنسيقات البريد الإلكتروني لجعلها أكثر قابلية للتخصيص حسب الموضوع، وذلك بفضل @neil.
لقد قمت بإعادة البناء للتو، لذا فإن هذا الإصدار يستخدم أحدث نسخة v2.4.2.beta2 من Discourse:
قمنا بتعطيل ملحق mlm-daily وتفريغ قائمة الانتظار لإعادة المحاولة أمس. ومع ذلك، لا نزال نلاحظ أخطاء في /logs ولا تزال إعادة المحاولة تتراكم في Sidekiq:
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined method 'apply_notification_styles' for #<UserNotifications:0x00007f6f971b9168>
يبدو أن هذا يؤثر على جميع الإشعارات، وليس فقط الملخصات اليومية. هل هناك حل بديل يمكننا تنفيذه حتى يتم الانتهاء من إعادة تصميم تنسيق البريد الإلكتروني؟
شكرًا،
Gunnar
يعود ذلك إلى إضافة طرف ثالث تستخدمها. ستحتاج إما إلى تحديث تلك الإضافة أو تعطيلها.
نواجه هذه المشكلة في تثبيتنا (الإصدار 2.4.0 بيتا4) أيضًا. هل هناك أي شيء أحتاج إلى تحديثه لحل هذه المشكلة؟
بالإضافة إلى ذلك، عندما يحاول المستخدمون تمكين وضع القائمة البريدية في إعداداتهم الخاصة، يتم حفظ التغيير (على الأقل يخبرنا الواجهة بذلك)، ولكن عند إعادة فتح نافذة الإعدادات، تكون خانة الاختيار غير محددة مرة أخرى. وبالتالي، لم نعد قادرين على استخدام هذه الإضافة لإرسال رسائل الملخص اليومية. لست متأكدًا مما إذا كان هذا مرتبطًا برسالة Jobs::HandledExceptionWrapper المذكورة أعلاه، لكنني أظن أنه ليس كذلك.
هل هناك أي إجراء يمكنني اتخاذه لحل هذه المشكلة؟
درك
يحتاج شخص ما إلى تحديث الإضافة لحل المشكلة. يمكنك قراءة مواضيع “كيفية” الخاصة بمطوري الإضافات أو النشر في “السوق” إذا كان لديك ميزانية.
مرحباً @joebuhlig.
هل ما زلت مستعداً للعمل على هذا الإضافة، وتحديثها لنسخة discourse القادمة 2.4، وإصلاح الخطأ المذكور سابقاً على أساس مدفوع؟ إذا أخبرتنا بالسعر (لقد ذكرت 200$ لإصلاح الخطأ في وقت سابق من هذا العام)، سنناقش ذلك في فريقنا.
شكراً لإخبارنا بذلك.
إتيان
هذا ليس تحديثًا حقيقيًا للإضافة بقدر ما هو إصلاح عاجل. لا يقوم فعليًا بتعديل الإضافة لتعمل مع النظام الجديد، بل يدمج الأجزاء التي تم إزالتها داخل الإضافة. هذا الحل ليس مستدامًا للمستقبل. وبالتأكيد لن يحل مشكلة اعتبار فريق Discourse لملخصات البريد الإلكتروني اليومية حالة هامشية غير ضرورية بدلاً من كونها جزءًا مهمًا لإبقاء المستخدمين الذين يفضلون البريد الإلكتروني على اطلاع. لم يعد من الممكن استخدام Discourse كبديل لقوائم البريد الإلكتروني، وإذا كانت لديك إمكانية الانتقال، فافعل ذلك. كما لن يحل مشكلة “لا نحتاج إلى توثيق أو ملاحظات إصدار صحيحة” < /rant>
مع ذلك، نحن نستخدم هذا الحل في بيئة الإنتاج ويبدو أنه يعمل. ليس مثاليًا، لكن ما هو إلا ما هو.
الآن يمكنك التبديل بين زر الواجهة الرسومية مرة أخرى.
def apply_notification_styles(email) email.html_part.body = Email::Styles.new(email.html_part.body.to_s).tap do |styles| styles.format_basic styles.format_html end.to_html email
لاحظ أن الدالة الأصلية (انظر الالتزام الذي كسر كل شيء لقراءة التفاصيل) كانت تستخدم styles.format_notification بدلاً من styles.format_html. نظرًا لأن _notification تم إزالته، فإننا نستخدم ببساطة _html. هل هذه فكرة جيدة؟ لا. هل تعمل؟ يبدو ذلك. على الأقل لدينا فرصة ضئيلة ألا يتم إزالتها مع التحديث التالي.
لقد قمت أيضًا بتغليف ملف mailing_list.html.erb بالكامل داخل وسم Div يحمل الكلاس summary-email، وقمت بتعطيل التصميم لرسائل الملخص في الإعدادات. كانت هذه مجرد محاولة يائسة في البداية ولم تحقق أي نتائج. على الأرجح ستعمل بشكل جيد بدونها، لكنني لن ألمس هذا الفوضى مرة أخرى ما لم ينكسر مرة أخرى. لذا إذا واجهت مشاكل في التنسيق، فلا تتردد في تجربة هذا.
آمل أن يكون هذا مفيدًا.