User Admin Email
Latest account activation email
Shows the date of the last account activation email. This filed is updated any kind of activation email was sent ( after registration, for request, reminder ).
If it is not set and user is not activated, it means activation email wasn’t sent.
This field is used to not allow users to request too many activation emails in a short period of time ( 5 minutes by default - So only one email is allowed in this topic in every 5 minutes ), and it is also used to store the last account activation reminder email datetime. When a user would like to request a second email with the same email address in 5 minutes this message is displayed: "We have already sent you an activation message to "firstname.lastname@example.org" at "exact time". Please allow "x" minutes for delivery before requesting a new one." If the user request another email in a different email address that will be sent straightaway.
We don’t have counter which shows how many activation email was requested, but we have a counter for the reminder emails ( see below ). We have a time limit ( 5 minutes by default - can be configured in the User Setting / Registration tab under the ‘Account activation’ fieldset. ), so only one activation email can be requested to a specific email address in every x minutes. We check the time difference between current time and last_account_activation_email only when the requested email address is the same as it was previously. If the user change his email address then everything starts from the beginning.
"Send reminders about not activated accounts" scheduled task:
We have a counter for the account activation reminder which counts how many reminder email was sent for a specific account. The scheduled task sends an activation reminder on +1, +2.5 and +7 days after the new user was registered, or the user status was changed to ‘new’, ‘deactivated’ or ‘emailchanged’ status. This last_account_activation_email datetime field and the activation_reminder_count values are used to get the exact time when should we send a new account activation reminder.
How does it know when an account status was changed back to ‘new’, ‘deactivated’ or ‘emailchanged’ ?
Account activation reminders are sent for each user which are not activated, and didn’t receive the max number of reminder emails yet ( This max number is 3 by default, and these emails are sent on +1 +2.5 or +7 days after registration or after deactivation ). When an account status was changed from a not active status ( deactivated, emailchanged, new ) to an active status ( activated, autoactivated ) then the last_activation_email and the activation_reminder_count fields are deleted. When an active user will be deactivated by some reason, it will be still able to get new account activation reminders, because the old counter was removed, so everything starts from the beginning. Also note that users may unsubscribe from the activation reminder emails, but after a new activate/deactivate process this subscription will be reseted.
Seven days after the last activation email, the account status will be changed to ‘failedactivation’ and no more reminder email will be sent to activate the account.
These settings ( number of reminders, the delay between the reminders, the ‘failedactivation’ threshold ) can be configured in the _advanced.php with the $activate_account_reminder_config variable.
Latest unread messages reminder
Shows the date when the last unread message reminder email was sent. This will be set after new private message notifications, and after unread message reminder emails as well. Unread message reminders are sent only in those cases when the user would like to receive this kind of notifications, and has at least one unread private message which is older the 24 hours.
Note: The new private message notifications show other unread threads as well.
This datetime is used for the unread message reminder cron job. There we select only those users who didn’t get message reminder in the last 3 days. In those cases when the user didn’t log in for a long time, then these three days period is delayed, as it is configured on the conf/_advanced.php $unread_message_reminder_delay variable
Next unread messages reminder
Shows how much time is required until the next unread message reminder email, if it is already known. In those cases when a reminder email should have been sent already, the pending time is displayed. If the user doesn’t want to receive this kind of notifications, or it doesn’t have unread private messages, then this information is displayed.
Latest notification email
Users may set a limit/day to the number of emails they want to receive per day ( this is 3 by default ). When x( = limit) emails were sent on a given day, then all additional notification emails are blocked.
This limit impacts new message notifications, unread message reminders, comment notifications, posts notifications, user activated/closed/reported notifications, and activate account reminders.
The notification email limit doesn’t prevent sending of newsletter (we have a different setting for that), and requested validation emails.
Technical information about the latest notification email: It is stored in ‘timestamp_number’ format, e.g. 1361961042_1. The timestamp shows when was the last email sent and the number part shows the number of notification emails on that day (the counter is relative to midnight). The counter reset will occur when the first notification email is sent on a day.
We also display "Notifications already sent today: x out of a maximum allowed of y" except in the case when there wasn’t sent any notification email yet
same as above for newsletters
Here are the important parts ( Some questions/thoughts which was not implemented were left out ) of the conversation about the Last notification email specification:
I want users to be able to set a limit. 3 by default.
If we have already sent 3 emails on a given day, we should block all additional notifications in send_email_to_User().
Ideally though, as soon as the user comes back to the site, I want to reset that count. The rationale is: if he read his pricate messages, he’s ok to get notifications if case of new PMs.
However I just thought about this: how about we reset the "daily email notifications counter", every time the user reads a previously UNREAD message (on disp=message or equivalent in backoffice)
I thought about another problem though: if a user has a conversation with another in real time, they may exchange 30 emails in an hour. So they’ll receive 15 notifications each which are not interesting at all because they already read the messages.
Because of this I think it’s best to stay with a limit of x (default 3) per day and check/reset the counter+date at the time we send notifications.
This should impact new message notifications, comment notifications, posts notfications and email reminders. Please be aware of the newsletter task I sent to Yura (did you get the cc: ?). This should NOT prevent the sending of the newsletter. However, I think it would be good to have another counter that prevents sending more than y (default 1) newsletters per day to the same user. Can you please check this after Yura implements the newsletter stuff.
If there are other kinds of emails that I didn’t mention and could benefit from limiting, please let me know.
Note: We also have a problem with activation emails. Some people send themselves 10 activation emails in 3 minutes. People now have to enter their email address again every time they request the activation message, right? I think we should detect if the users asks for an activation email that has already been sent to the EXACT SAME email address within less than 5 minutes and in this case give them a message like "We have already sent you an activation message to email@example.com at date time. Please allow 5 minutes for delivery before requesting a new one."
Also, you will know better but maybe the 5 minute rule is only valid if the email is equal to the LAST email entered for the account if they do address A then address B then address A again, we may accept to sent to A again in less than 5 minutes because the first email is no longer valid… ? do I get that right?
Basically I am done with this task and I have used the most simple solution. The number of notification emails limit and newsletter emails limit can be set, and we won’t send more email what this limit allows. The counter reset will occur when the first notification/newsletter email is sent on a day.
There is no scheduled task for this, and there is no queue to hold not notified messages. So if a user has a conversation with another user in the morning of a day, and he receive three new private message, then that user will get three new pm notification, and if this user’s limit is three then he won’t get any new notification in that day.
I have chose this solution because the solution you have suggested ( tsta_first_unnotified_msg_ID or messaging__thread_status.tsta_
was_notified ) are only good for private messages. We do handle the same way all notifications which can be private message notification, new post notification, new comment notification, and others too.
Created by • Last edit by on Sep 28, 2015