Use the Rules module together with Rules Scheduler
(a sub-module of it), as explained in the steps below. These steps are based on a date field which is added to the user profile, so that for each user you can indicate an appropriate date.
Step 1: Create a field to store the reminder date
Similar to that "Entry date" field you already have, add another field to the "user" entity with machine name (say) field_next_reminder
. Allow only 1 date (to store the date of the "next" reminder), I don't see any reason why you'd want to make it required (it doesn't matter in the context of this answer). And set its initial value to "5 years after the entry date", using the same procedure you have in place already for that "Entry date".
Step 2: Create a Rules "Component"
Here is the Rules Component to be created (in Rules export format, just import it in your own environment via copy-paste, which you can do using the "Import rule" link located at admin/config/workflow/rules
):
{ "rules_send_email_notification" : {
"LABEL" : "Send eMail notification",
"PLUGIN" : "action set",
"OWNER" : "rules",
"REQUIRES" : [ "rules" ],
"USES VARIABLES" : { "user_to_be_reminded" : { "label" : "User to be reminded", "type" : "user" } },
"ACTION SET" : [
{ "mail" : {
"to" : "[site:mail]" ,
"subject" : "Time flies ...",
"message" : "This is a reminder about another 5th anniversary for user with eMail id [user-to-be-reminded:mail] on [user-to-be-reminded:field_next_reminder] ...",
"language" : [ "" ]
}
}
]
}
}
Obviously, the Subject and Content of the eMail may need review / tuning, while you might also want to use some other To eMail ID.
Step 3: Create a "Rule" using the Rules Component
Here is the Rule to be created, in Rules export format (just import it in your own environment via copy-paste, which you can do using the "Import rule" link located at admin/config/workflow/rules
):
{ "rules_on_new_user_registration" : {
"LABEL" : "On new user registration",
"PLUGIN" : "reaction rule",
"OWNER" : "rules",
"REQUIRES" : [ "rules", "rules_scheduler" ],
"ON" : { "user_insert" : [], "user_update" : [] },
"IF" : [
{ "entity_has_field" : { "entity" : [ "account" ], "field" : "field_next_reminder" } }
],
"DO" : [
{ "schedule_delete" : {
"component" : "rules_send_email_notification",
"task" : "[account:name]"
}
},
{ "schedule" : {
"component" : "rules_send_email_notification",
"date" : {
"select" : "account:field-next-reminder",
"date_offset" : { "value" : 2592000 }
},
"identifier" : "[account:name]",
"param_user_to_be_reminded" : [ "account" ]
}
}
]
}
}
Note that the above rule refers to the Rules Component from the previous step.
Also note the machine name of field_next_reminder
in this rule, which is the field's machine name created in Step 1 (if in step 1 you used another machine name, then also replace the machine name field_next_reminder
in this rule with the machine name of the field created in Step 1 (if you don't have such field yet, or the field names don't match, then the import of this rule might not work).
The schedule_delete
part of this rule ensures that previously "scheduled" reminders are removed when updating the data field (so that it only triggers 1 reminder, and with the most recent date).
Step 4: Add 5 more years to the reminder date
With what's above you should receive such reminder eMails after 5 years. But you also want that to happen after 5 (or 10) years later on (for 10 years or 15 years).
Probably the easiest way to do so, is to have some mechanism in place so that around the time you actually perform some action (to process your reminder), you also add 5 more years to the field_next_reminder
. In doing so, the above magic will get triggered again (via that very same rule).
You can apply such update manually (don't forget it though). Or (my preference) you could use the Flag module to implement a designated (global) flag to flag users. And combine this with an extra custom rule with these specs:
True, this would be a minor extra effort to get it implemented (it may take up to 5 minutes, say 15 at most ...). But the ROI of doing so would be that authorized users would only have to flag those yearling-type of users (somewhere after they receive the reminder eMail ... in which you could even include a relevant hyperlink to make the magic happen). Even better: you could use this flagging facility to start nagging yourself to not forget to flag that user ... (logic: reminder date is below 30 days, and user is not yet flagged).
Step 5: Further tuning and enhancements
The date_offset (=2592000) in the above rule corresponds to "30 days in advance", which may need review / tuning (it's about 1 month, right?).
You might want to also use the Field Permissions module to set field-level permissions to edit, view and create fields on any entity. In your case maybe you only want admins to edit that reminder field.
5 years is a long time ... remaining homework: what if the user account has been deleted.
Instead of just sending an eMail (as in the Rules Component), you could replace that by a more advanced option using the Message module (which has great integrations with the Rules module also). Here is an quote about that module (from its project page):
... enables logging and displaying system events in a number of different use cases. Events that are recorded over time are sometimes call activity streams. Exportable messages subtypes can be created for different use cases with custom fields and display (view) modes.
Step 6: User boarding
With the above solution in place, you have a solution for (a) all future new user accounts that will be created and (b) all existing accounts for which a date is entered (manually?) in that field_next_reminder
field. However you could take advantage of that existing "Entry date" you mentioned, to also get a similar process in place for your existing user accounts, by performing an (one time only) appropriate mass update (bulk) operation. If you wonder how to also get that to work, then use this link.
Note: Using Rules to send an email X days after a user registers also contains quite some details that may help you.