To do what you're asking for, I would only use the Rules module, and the Rules Scheduler (a submodule of it), as further explained below.
Step 1 - Create a Rules Component
Create a Rules Component which looks like so (in Rules export format):
{ "rules_send_notification_to_og_members" : {
"LABEL" : "Send notification to OG members",
"PLUGIN" : "rule",
"REQUIRES" : [ "rules", "og" ],
"USES VARIABLES" : { "current_node" : { "label" : "Current node", "type" : "node" } },
"IF" : [
{ "node_is_of_type" : {
"node" : [ "current-node" ],
"type" : { "value" : { "book" : "book" } }
}
}
],
"DO" : [
{ "og_get_members" : {
"USING" : { "group_content" : [ "current-node" ] },
"PROVIDE" : { "group_members" : { "group_members" : "List of group members" } }
}
},
{ "LOOP" : {
"USING" : { "list" : [ "group-members" ] },
"ITEM" : { "group_member" : "Current group member" },
"DO" : [
{ "mail" : {
"to" : [ "group-member:mail" ],
"subject" : "Friendly reminder about some post in group",
"message" : "Hello [group-member:name],\r\n\r\nThere is a reminder about a post with title [current-node:title] (located at [current-node:url]) which belongs to one of the groups you are subscribed to.\r\n\r\nSome more details about this node:\r\n\r\n- Price: [current-node:field-book-price]\r\n- Release Date: [current-node:field-book-release-date]",
"language" : [ "" ]
}
}
]
}
}
]
}
}
Some details about the above Rules Component:
- Component Variables: only a "node" (of type "node"), of type "parameter", labeled "Current node", and machine name
current_node
.
- Rules Condition: use whatever extra condition you need/want, but actually you may not need any at all. As a sample, I just used "Content is of type" (with actual type =
book
).
- Rules Actions:
Get group members from group audience
, for current_node
, and store the result in a list with machine name group_members
.
Perform a Rules Loop
, for each item in the group_members
list, whereas the item is named group_member
. And for each iteration of this loop, send an eMail to the group member being processed, with all sorts of data about the node included in the eMail title and/or eMail body (use your own imagination to make it fit your needs).
Step 2 - Create a Rules which schedules the Rules Component
Create a Rule which looks like so (in Rules export format):
{ "rules_remind_og_members_about_node_content" : {
"LABEL" : "Remind OG members about node content",
"PLUGIN" : "reaction rule",
"REQUIRES" : [ "og", "rules", "rules_scheduler" ],
"ON" : [ "node_insert", "node_update" ],
"IF" : [
{ "og_entity_is_group_content" : { "entity" : [ "node" ] } },
{ "entity_has_field" : { "entity" : [ "node" ], "field" : "field_book_release_date" } }
],
"DO" : [
{ "schedule_delete" : {
"component" : "rules_send_notification_to_og_members",
"task" : "Notify-OG-members-for-node-[node:nid]"
}
},
{ "schedule" : {
"component" : "rules_send_notification_to_og_members",
"date" : {
"select" : "node:field-book-release-date",
"date_offset" : { "value" : -259200 }
},
"identifier" : "Notify-OG-members-for-node-[node:nid]",
"param_current_node" : [ "node" ]
}
}
]
}
}
Some details about the above Rule:
- Rules Events (either of both):
- After saving new content.
- After updating existing content.
- Rules Conditions (all conditions must be true):
Entity group content
, for entity = node.
Entity has field
for field field_book_release_date
, which is defined as a date field, and which you could consider as something like the release data of a book. Note: for nodes which don't have that field, or for which it is empty, this Rules Condition is false (so no Rules Actions will be performed).
- Rules Actions:
Delete scheduled task
, with Notify-OG-members-for-node-[node:nid]
as the "Task identifier", whereas the task refers to the Rules Component created in Step 1.
Schedule component evaluation
, with Notify-OG-members-for-node-[node:nid]
as the "Task identifier", whereas the task refers to the Rules Component created in Step 1. And the actual date to schedule the execution of this Rules Component, is the date indicated in the node's field field_book_release_date
, but with an offset of -3 days
(pick whatever value for this offset the fits your needs), so 3 days before the date indicated in that field, the Rules Component is executed.
To be complete: the first Rules Action (to delete the previously scheduled task with the very same Task identifier), is to ensure that the Rules Component is only executed once. The typical scenario is that first the node gets created (and the Rules Component is scheduled accordingly). But later on the node is updated. In that case, the request to execute the previously scheduled Rules Component is deleted, and a new request is scheduled again. And if the date itself was not updated, it will be scheduled for execution at the very same moment. But if the date was updated also, only the date of the most recent update will be taken into account. For this mechanism to work, it's important to use a unique Task Identifier, to be used in both Rules Actions. That's why I added the token [node:nid]
to it (with a prefix like Notify-OG-members-for-node-
so that it can be recognized by somebody looking at the currently scheduled Rules Components also).
Bonus tip - Resolving potential access issues
By using the Rules Scheduler, in the end the Rules Component will be executed when cron is running (the very first time after the date/time the Rules Component was asked to be scheduled). But cron jobs always run with user Anonymous.
So the question that remains is: "How will the eMail content look like if you're processing a node for which an anonymous user has no access?". If you run in any such access issues, the easiest workaround I can think of is that you improve the Rules Component by adding additional variables (used as "Parameter"), and so that these variables contain the values of the relevant node's fields that you want to be able to refer to in the eMail to be created. Since the user who triggers the Rule from Step 2 (due to a create or update of a node) should have (read) access, for sure these values will be passed to the Rules Component at the time of scheduling the Rules Component.
PS: I'm assuming this question is about D7.