I've been examining this module which I find to be good and well extend-able. There is however a problem that I need to solve. My client made a requirement that all notifications are sent in a given day of the week. Meaning send all notifications on a requested day/time/minute of the week.
The client wants to create a content on say Monday and publish&notify all users on Thursday.

What I see as a solution is possibility to use crontab like entry along intervals (crontab entry would override intervals).

Now there is a workaround for my problem with usage of Rules & Scheduler which I'm afraid is very unreliable. My concern:
- customer creates content on Monday but doesn't publish it
-- notifications memorizes this but does not send notification since content is not published
- using Rules&Scheduler I can publish the content on say Thursday
-- notifications will start sending notifications all around
**my concern is that customer can (by mistake) publish the content

If you believe that this could be integrated into the code I'll be more than willing to send you a patch that addresses this feature.

Comments

joshuajabbour’s picture

@gregord did you ever come up with a solution to the crontab-like specific timing functionality? I need a similar feature, and am beginning to develop it. Just wondered if you had gotten anywhere...

Jose Reyero’s picture

Status: Active » Fixed

May I suggest you take a look at the 4.x branch (actually Beta4)?

That version has some more options built in, like the ability to disable cron processing and do it with a drush command (to create notifications) and a full featured message queue (you can mark sending methods to be queued and again disable cron), so all messages can be queued (drush sending still pending though so the option atm is to re-enable cron)

So properly set up you have actually two options to stop sending out notifications and enable them again any time.

The 2.x branch has just rome rough queueing, no new features planned for this one.

joshuajabbour’s picture

Title: cron entry instead of intervals » time-based sending instead of intervals
Version: 6.x-2.2 » 6.x-4.x-dev
Status: Fixed » Active

My understanding of gregord's original request was to implement specific-time-based sending periods (in place of, or in addition to, the current interval-based time periods). example: notification x could be set to be sent on wednesday at 9:00 (or as close to that as the next cron run).

This is something I need for my current project, and it seemed like he might have gotten somewhere with it previously. So if this isn't something he solved, I plan on attempting to implement it...

Jose Reyero’s picture

Jose Reyero’s picture

Hey Joshua,

If you're still wondering how to do this I've been thinking of a possible solution.

There's this 'notifications_sent' table with: uid, mdid, send_interval, send_method. It basically keeps track of last time a notification was sent for a user for that interval.

By tweaking the 'sent' timestamp, you can force the notification to wait until the next "sent + send_interval" time. An example:

- if sent = current time
- send_interval = 3600 (1 hour)

The next notifications for that user (for this interval) won't be sent until current time + 1 hour. So by setting an initial value there we can set up (minutes up or down) when the next notification will be sent.
Then we just need to periodically update that values for some expected time shifting: if the notification is sent it may be at that time + some minutes, so we'd need to re-adjust the time. If not sent, we need to reset that 'sent' time to + 1 hour.

Does this make sense? Will it work?

That would mean a global setting for each user like "Weekly notifications are sent Mondays at 9 pm".

Optionally we could add a 'when' timestamp for the notifications_queue table, to be populated after the queue row is created depending on user settings. Maybe this one would be easier.

Jose Reyero’s picture

Yes, my solution above was not the best one.

So I've just added support for scheduled notifications. See the new 'send_time' field in notifications_queue. You'll need some add-on module for setting that value though.

zeezhao’s picture

subscribing

jun’s picture

Title: time-based sending instead of intervals » time-based scheduled sending in addition to intervals

Dear Jose,

This "Scheduled" sending feature sounds like a quite good feature to put in the notifications module itself, I wouldn't want to question your suggestion to put it in an add-on module, but it seems that not specifying a time zero for intervals should be the optional feature.

I see also an opportunity to clarify in the interface when the interval is supposed to start as of now (I'm not quite sure to be honest if its the time of registration of the user or the time when the first event is triggered). Notification "schedules" (instead of intervals) could be defined as:

  • Interval
    • Custom (allows to specify any duration/unit like what the module allows now)
    • Hourly
    • Daily
    • Weekly
    • Monthly
  • Send time
    • default : at user registration time/date?
    • daily : HH:MM
    • weekly : D HH:MM
    • monthly : DD HH:MM
  • User defined : allows user to specify a time (in his user profile edit page), then the "Send time" field is used as a default time.
  • Display Name + Format + Default

Hope this makes sense! And bravo for a great module!

Best,

Jun.

Crom’s picture

Hi Jose, great module - thank you!

I'm probably being a fool but I can't see the notifications_queue anywhere on the admin menu and can you explain which add-on modules I will need to implement the scheduled notifications.

Thank you,
Crom

kenorb’s picture

+1

Crom: notifications_queue
#797828: Support for high performance queue processing: improving queue API

We have now:
new class Notifications_Queue
function notifications_queue()

Note this doesn't add any new feature. It just allows overriding the queue & processing API by setting 'notifications_queue' variable.

thePanz’s picture

Subscribe! I could implement something in this direction, could you give me some pointers for overriding methods I need to implement? Maybe we could share our efforts @jun, @jose, @kernob?

@Crom: the notification_queue is a table in your Drupal database

rjbrown99’s picture

I'm kind of after what Jun mentioned. If a user selects "twice a day", they should be able to select which time the digest is sent (i.e. they select 12 = digest sent noon and midnight). Same with once a week, select the day and time. And it should respect the user's timezone settings so it goes out at the right time for them. There should also be a default in the admin page for this, so for example the admin could set the default for twice a day to 9AM or whatever and the user overwrites it. This gets a bit granular, but from a user and functionality standpoint it could increase the chance the digest is read.

I don't have time to write this at the moment, but I'd be happy to talk about an approach as I will eventually need to do this.

cjback’s picture

Subscribe! As a drupal newbie this is a great idea and would solve alot of requests by my users.

cjback’s picture

Has anyone been able implement any of the work arounds described in this thread? I have to have the daily digest send every day at 9 am. I'm struggling with the possible solution in #5 setting values in 'notifications_sent' table. Any additional ideas would be greatly appreciated.

goldlilys’s picture

Subscribing

cjback’s picture

Using idea in #5 here is my implementation for sending daily notifications at 9 AM every day

Calculated last sent time:
Table: notifications_sent
Fields:
sent (this field is updated when notifications are sent per specific user with specific time interval)
send_interval (interval 86400 = 1 day)

Queued notifications are sent when sent+send_interval < now

How to send daily digest at 9 AM every day:
1. Create a mysql account with at least "Select table data" and "Update table data" permissions

2. Create a scheduled cron job to run at 9 AM every day and run the command below . Sql query will update field sent to 9 AM the day before (this is why have to run at 9 AM) where the send interval is one day
Command (make sure to replace username and password):
mysql -u -p
-e "Update changes.notifications_sent Set sent = UNIX_TIMESTAMP(DATE_SUB(now(), INTERVAL 1 DAY)) WHERE send_interval = 86400;" >> /var/log/cron.log

Optional:
Ensure drupal cron is running at least once an hour (or directly after 9 AM everyday). I have poormanscron installed and according to the documentation it requires a certain amount of activity on the site to prompt to run. My site has low activity on the weekends but queued notifications still need to be sent. Until I get the cron/poormanscron piece completely figured out I have a device calling https://mydrupalsite/cron.php once an hour

My setup:
Operating system -> Ubuntu Linux 10.04.2
Webmin version 1.560 (Using webmin to administer linux box
Drupal -> 6.20
Notifications -> 6.x-4.x-dev
MySQL database -> 5.1.41

caspercash’s picture

Issue summary: View changes

Hi everyone! Are there any new updates to this thread? Is there another way to implement this without touching the database manually? I think it would be helpful if this will be implemented like what jun suggested in #8.