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
Salut @joebuhlig et les autres utilisateurs de ce plugin — Est-ce que quelqu’un d’autre rencontre des problèmes avec ce plugin depuis la version 2.3.0 de Discourse ? Lorsque notre hébergeur nous a mis à jour vers la version 2.3.0 il y a quelques semaines, nos e-mails quotidiens ont cessé d’être envoyés. De plus, lorsque je visite l’écran des préférences de messagerie d’un utilisateur, la case à cocher pour cette option d’e-mail refuse d’être enregistrée. Vous pouvez cliquer dessus et enregistrer, mais lorsque vous rechargez la page, elle est décochée. Je me demande simplement si quelqu’un a trouvé un moyen de résoudre ces problèmes. Merci beaucoup si vous avez des pistes !
Salut Leah, consulte mon message précédent du 29 janvier et vérifie si ton problème pourrait également être lié à l’entrée dans user_custom_fields ? Salutations, Etienne
J’ai quelques mises à jour et j’aimerais beaucoup avoir votre retour, à tous ceux qui utilisent ce plugin, sur son fonctionnement actuel. Nous avons des centaines d’abonnés aux courriels quotidiens, nous espérons donc pouvoir faire fonctionner ce plugin à nouveau.
@etienne, merci d’avoir partagé vos constatations concernant le vrai/faux (v/f). Quelqu’un a examiné le problème et a indiqué que le code semblait pouvoir le gérer correctement. Donc, dans notre cas, je suis toujours perplexe quant à la raison pour laquelle certains utilisateurs ne reçoivent pas les courriels quotidiens, tandis que d’autres ne les reçoivent que tous les quelques jours. Nous avons définitivement de nouveaux sujets et de nouveaux messages chaque jour, donc ce courriel devrait être envoyé quotidiennement.
Notre développeur WordPress (qui n’est pas vraiment un expert de Discourse/Ruby, mais quelqu’un qui était prêt à examiner le problème) a réussi à résoudre l’erreur JavaScript côté front-end qui empêchait la case à cocher d’être enregistrée.
Une autre chose que je me demande, auprès de toute personne utilisant ce plugin, est la suivante : soupçonnez-vous que ce plugin puisse planter et verrouiller des tables de manière problématique ? Nous rencontrons un autre problème mystérieux sur notre forum, et une théorie suggère que ce plugin pourrait en être la cause en raison de tables verrouillées qui ne sont pas déverrouillées, mais nous n’avons pas encore confirmé cela avec certitude.
Salut,
J’ai mis à jour mon Discourse vers la version 2.4.0 beta2. Depuis, ce plugin ne fonctionne plus.
Pour l’instant, mon code d’erreur dans Sidekick est :
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined methodapply_notification_styles’ for #UserNotifications:0x00007f1437382668`
J’espère que ce plugin sera corrigé bientôt.
Nous constatons cela aussi.
Probablement parce que nous unifions tous les styles d’e-mails pour les rendre plus adaptables aux thèmes, grâce à @neil.
Je viens de reconstruire, donc ceci est avec la dernière version v2.4.2.beta2 de Discourse :
Nous avons désactivé le plugin mlm-daily et vidé la file d’attente des nouvelles tentatives hier. Nous constatons toujours des erreurs dans /logs et les nouvelles tentatives s’accumulent toujours dans Sidekiq :
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: méthode apply_notification_styles’ non définie pour #UserNotifications:0x00007f6f971b9168`
Il semble que cela affecte toutes les notifications, pas seulement les résumés quotidiens. Existe-t-il une solution de contournement que nous pouvons mettre en place jusqu’à ce que la refonte du style des e-mails soit terminée ?
Merci,
Gunnar
Cela est dû à un plugin tiers que vous utilisez. Vous devrez soit mettre à jour ce plugin, soit le désactiver.
Nous rencontrons également ce problème dans notre installation (2.4.0 beta4). Y a-t-il une mise à jour spécifique à effectuer pour corriger cela ?
De plus, lorsque les utilisateurs tentent d’activer le mode « Liste de diffusion » dans leurs propres paramètres, cela semble être enregistré (du moins l’interface l’indique), mais lors de la réouverture de la boîte de dialogue des paramètres, la case à cocher est de nouveau décochée. Ainsi, nous ne pouvons plus faire en sorte que ce plugin envoie les résumés quotidiens par e-mail. Je ne sais pas si cela est lié au message Jobs::HandledExceptionWrapper mentionné ci-dessus, mais je suppose que non.
Y a-t-il quelque chose que je pourrais faire pour résoudre ce problème ?
Dirk
Quelqu’un doit mettre à jour le plugin pour résoudre le problème. Vous pouvez consulter les sujets howto du développeur de plugin ou poster dans Marketplace si vous avez un budget.
Bonjour @joebuhlig.
Êtes-vous toujours disposé à travailler sur ce plugin, à le mettre à jour pour la prochaine version de Discourse 2.4 et à corriger le bug décrit précédemment, sur une base rémunérée ? Si vous nous indiquez un prix (vous aviez mentionné 200 $ pour la correction du bug plus tôt cette année), nous en discuterons au sein de notre équipe.
Merci de nous tenir informés.
Étienne
Ce n’est pas vraiment une mise à jour du Plugin, mais plutôt un correctif urgent. Il ne corrige pas vraiment le plugin pour qu’il fonctionne avec le nouveau système, mais intègre plutôt des parties qui avaient été supprimées dans le Plugin. Il n’est pas pérenne. Et il ne corrigera certainement pas le fait que l’équipe de Discourse a jugé les résumés quotidiens comme un cas limite inutile plutôt qu’un élément important pour maintenir les utilisateurs qui préfèrent les e-mails informés. Discourse ne peut plus vraiment être utilisé comme remplacement d’une liste de diffusion et, si vous le pouvez, vous devriez partir. Cela ne corrigera pas non plus le problème du « nous n’avons pas besoin de documentation ni de notes de version appropriées » < /rant>
Cela étant dit. Nous l’utilisons en production et il semble fonctionner. Ce n’est pas bien, mais peu importe.
Maintenant, vous pouvez à nouveau basculer le bouton de l’interface utilisateur.
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
Notez que la fonction originale (voir le commit qui a tout cassé pour suivre) utilisait styles.format_notification au lieu de styles.format_html, puisque _notification a été supprimé, nous utilisons simplement _html. Est-ce une bonne idée ? Non. Est-ce que ça marche ? Il semble que oui. Au moins, nous avons une légère chance que cela ne soit pas supprimé avec la prochaine mise à jour.
J’ai également enveloppé l’ensemble du fichier mailing_list.html.erb dans une balise Div avec la classe summary-email et désactivé le thème pour les e-mails de résumé dans les paramètres. C’était juste une tentative désespérée au début et n’a donné aucun résultat. Vous serez probablement très bien sans cela, mais je ne toucherai plus à ce gâchis à moins que cela ne se brise à nouveau. Donc, si vous rencontrez des problèmes de mise en forme, n’hésitez pas à essayer cela.
J’espère que cela vous aidera.