Project

General

Profile

Feature #333

Delay Forum Notification Email Delivery Until After Editing Period Ends

Added by Matt Gold over 8 years ago. Updated over 3 years ago.

Status:
Assigned
Priority name:
Low
Assignee:
Category name:
Email Notifications
Target version:
Start date:
2010-09-13
Due date:
% Done:

0%

Estimated time:

Description

If we are giving members 15 minutes or so to edit forum posts, perhaps we should delay sending the email notifications until that period expires. That's how the old Moodle system works, and I think it's a good system. One cause of the errors in #332, for instance, might have been curved quotation marks pasted from MS Word that were corrected during the editing period.

History

#1 Updated by Matt Gold over 8 years ago

  • Subject changed from Delayed Forum Notification Post Emails to Delay Forum Notification Email Delivery Until After Editing Period Ends

#2 Updated by Boone Gorges over 8 years ago

  • Target version set to Future release

This kind of thing will require a large amount of development. Forum notification emails are not currently stored, but are generated on the fly, sent immediately, and then forgotten about. This essentially amounts to a digest system. As a result, it will be much easier to implement when there's a digest system in place, which is slated for 1.1. Even with the digest system, there will be a fair amount of dev required, so I'm going to tag it for Future Release and probably shoot for it in 1.2 if there's no objection.

#3 Updated by Matt Gold over 8 years ago

  • Priority name changed from Normal to Low

No objection. This would be a nice feature to have but it's not high priority. In fact, I'll reclassify the priority as low.

#4 Updated by Boone Gorges over 7 years ago

  • Tracker changed from Bug to Feature

#5 Updated by Boone Gorges over 6 years ago

  • Assignee changed from Boone Gorges to Dominic Giglio

Reassigning to Dom. Dom, the plugin that handles digests is buddypress-group-email-subscription. It has the basic infrastructure for scheduling emails. Maybe you could have a look at how it works and make some suggestions for a technical course of action.

#6 Updated by Dominic Giglio over 6 years ago

Boone,

I've looked through the plugin that handles this functionality and I see that the digest is handled mostly through WP's cron functionality. My first thoughts on a potential fix would be trying to use cron to set one-off (single event) notifications that are created when a new forum post is submitted, but I think that might get a little unwieldy on a large, high traffic site. There would be potential cron jobs all over the place. Then I thought we might be able to leverage the transients api. We could set a transient with an appropriate expire time and then every time wp loads (or more specifically when the plugin is instantiated) it could look for expired transients and fire off an email for each one. I'm not sure about the performance implications for this idea though. All that db access and the logic needed to keep track of which notices have been sent, plus would we keep the actual content of the forum post in the transient or pull that specific post back outa the db when its associated transient has expired? Sounds like a lot of work.

Also, I'd like to say this doesn't really sound like a "feature" to me. What I mean is: we may be opening up a whole slew of support emails about these delayed notifications. Think about this, a user posts a new forum entry, then 15-30 minutes later a notification is sent to all email subscribers. Those members that have already seen (on the web), and maybe even replied to that original post, are now getting notifications after the conversation has taken place. Think about very active forums, think about how much conversation can take place in 15-30 minutes! We could potentially be inundated with support requests claiming that forum notifications are always late and sent after the fact, which could be VERY confusing to members in an active forum.

If this feature is designed to help prevent users from getting garbage in their posts, we may be better off exploring ways to improve the error handling earlier during creation of the initial post, thereby preventing the types of errors that lead to the opening of this ticket.

#7 Updated by Matt Gold over 6 years ago

Interesting thoughts, Dom. I'll let Boone speak to the technical issues, but as far as users go, I don't think this will be a big deal, especially if we shrink that 15-30 minute window down to, say, 5 minutes. The key thing is to give users a short chance to edit their posts before the posts get sent out far and wide. I think that the number of users who respond as quickly as you suggest above are actually pretty small. And the issue is not so much with error handling (despite what my quotation example above says) as giving users a chance to edit before the email gets sent.

One other alternative to this system, though, is giving users a chance to preview their posts before they go live. Of course, that can introduce other problems (users may think they've posted when, in reality, they've only previewed).

#8 Updated by Dominic Giglio over 6 years ago

Matt,

I think you're right about the 5 min. That's much more feasible. The preview is definitely an interesting idea. Even something as simple as the preview below these updates here on Redmine.

Boone,

What do you think about not adding this functionality as a new feature in the plugin, but instead spooling the messages in the GC mail server?

#9 Updated by Boone Gorges over 6 years ago

I agree with Dom's original sentiment that a delay seems like sort of a kludgy way to deal with this.

but I think that might get a little unwieldy on a large, high traffic site. There would be potential cron jobs all over the place.

The transient solution that you suggest is, almost to a T, exactly how wp-cron works. It's not real cron. It just checks, on each page load, to see whether any scheduled events are due, and if so, it places a request to the pseudocron runner (wp-cron.php). If we're going to do this, I suggest that we do use WP's core features, instead of building our own version.

What do you think about not adding this functionality as a new feature in the plugin, but instead spooling the messages in the GC mail server?

I'm not sure how this would work (I don't know a lot about how spooling works in general). There are a number of application-side considerations: (a) we only want to delay email notifications of forum posts; (b) we need to have unique identifiers for emails, so that if I post to thread A, which triggers email A1, and then edit my post to trigger A2, the system has to know that A2 supersedes A1 (in cases where there could be a ton of email notifications in the queue). I'm not sure that our outgoing mail server has enough information about the emails to decide these sorts of things; it seems like it should be done from the WP end.

I agree generally that this should not be a default feature in the Group Email Subscription plugin, because it adds a ton of overhead for marginal benefit. My sense is that we should make it a secondary WP plugin (I can add hooks to BPGES if we need them).

#10 Updated by Matt Gold over 6 years ago

Thanks, Boone. If there are technical reasons (potential server load, etc.) not to do this, we can live without it. But I do think it would be a nice feature to have if we can swing it. What do you think about a post preview as an alternative? In the past, I know you've been skeptical of the need for a preview feature, but I think that for many people, seeing a forum post in "publication" form enables them to do a different kind of proof reading than they are able to do while reading the text in the posting box. It seems to me that a preview button might be a more lightweight way of accomplishing the goal here, which is to give members a chance to proofread their posts before they are emailed out to groups.

#11 Updated by Boone Gorges over 6 years ago

I'm not opposed to the Preview functionality in principle, I'm just not sure how it should be implemented. See http://redmine.gc.cuny.edu/issues/589 I am going to write a few more thoughts on that ticket.

If it's between doing an email delay and a preview, I would far prefer the preview.

#12 Updated by Dominic Giglio over 6 years ago

I'm not sure how this would work (I don't know a lot about how spooling works in general).

There's only one thing I am absolutely sure of when it comes to the field of Computer Science:

I do not want to be an admin for an email server.

So my knowledge of spooling is probably even less than yours. I was just running through all the possible avenues in my head to try and come up with a cleaner solution than constantly sticking expiring info into the DB.

Heading over to read your update to #589 now...

#13 Updated by Boone Gorges over 3 years ago

  • Category name changed from BuddyPress (misc) to Email Notifications
  • Assignee changed from Dominic Giglio to Raymond Hoh

Ray has been doing some work in BPGES on offloading email sending to a cron job. If that were in place, it'd be possible to piggyback an editing-window delay like what's being suggested here.

Also available in: Atom PDF