Open rjw57 opened 8 years ago
I see at the moment the notification emails are recorded into the Email log->Emails table, unless something like settings PINAX_NOTIFICATIONS_BACKENDS=[("email", "pinax.notifications.backends.email.EmailBackend"),] is set.
Is the intention to continue to create the messages in this table then run a scheduler to send the messages later, during the night?
Another scheduler will be required to populate the email table with the nags eg you have not had any meeting with X for Y weeks etc.
On 2017-02-14 16:06, StephenS wrote:
I see at the moment the notification emails are recorded into the Email log->Emails table, unless something like settings PINAX_NOTIFICATIONS_BACKENDS=[("email", "pinax.notifications.backends.email.EmailBackend"),] is set.
Is the intention to continue to create the messages in this table then run a scheduler to send the messages later, during the night?
I hadn't really got as far as a design for this but it seems sensible to me to make the recording of intent to send email separate to the request->render->response pipeline.
Another scheduler will be required to populate the email table with the nags eg you have not had any meeting with X for Y weeks etc
-- Dr Rich Wareham
I think that it would be useful for the notification to be sent immediately in some cases for example:
However it would also be nice to have a log of these notifications, which if just sending immediately I don't think happens automatically.
For the periodic reminders then yes dong these in bulk at a particular time I think could would be helpful.
I'm slightly split, and I'm not sure if I found a clear way to dictate from the 'send()' which route a message would take (direct or via Email log).
On 2017-02-14 16:16, StephenS wrote:
I think that it would be useful for the notification to be sent immediately in some cases for example:
- when a users registers a meeting, to avoid the other party adding the same meeting
- when a user sends or accepts an invite
However it would also be nice to have a log of these notifications, which if just sending immediately I don't think happens automatically.
For the periodic reminders then yes dong these in bulk at a particular time I think could would be helpful.
I'm slightly split, and I'm not sure if I found a clear way to dictate from the 'send()' which route a message would take (direct or via Email log).
I think I was envisaging some sort of message queue. The time between "send email" appearing in the database and the email being sent can be very low; the sending server could check every 15 seconds. I just think it should not be on the critical path for two reasons:
-- Dr Rich Wareham
Celery looks as though it logs and capture issues. Also need to find out if it can be used to temporarily disable email.
I'll take a look at Celery (http://celery.readthedocs.io) in branch REST-Celery.
(Unless there are know issues or other leads)
Having taken a look it seems as though using mysql as the broker for Celery isn't a good idea. They suggest RabbitMQ or Redis though to install either on MWS requires a fair amount of work.
I've used the pinax-notifications emit_notices management command. Happy to write a specific one for autonag but wasn't too sure what else it should do other than send messages and check for exceptions.
What should happen with new member nag?
On loading a new user -> are they to get a 'congratulations' message?
Can we create another management command to search for things to nag and create the notifications (and for now keep the logic in the code; how many nags are there?)
The autonag application provides a management command which will run daily and send the "autonag" emails. The command should be idempotent in that running it repeatedly will net affect the frequency of emails sent.
Tasks:
We can add more nags as other parts of the software are implemented.