Hello,
When an activity is restricted to a specific group, the Reengagement plugin’s cron task still sends emails to managers only—even though students in the target group meet the delay criteria. No student ever receives the reengagement email. Reengagement plugin (version 2023020805) tested on Moodle 4.2 and 4.5.
Steps to reproduce
In a course, create a Reengagement activity and configure “Email user” to send after a delay.
Under “Restriction of access”, add a Group restriction (e.g. “Group B”).
Enroll at least one student in Group B and another student outside Group B. Also enroll a manager.
Wait for the configured delay to elapse and run the cron (php admin/cli/cron.php).
Actual behavior
Only the managers receives the reengagement email.
No student—neither inside nor outside Group B—receives any email.
Expected behavior
The student(s) in Group B should also receive the reengagement email.
Root cause
In mod/reengagement/lib.php, the function reengagement_get_startusers() builds its candidate list by calling:
$information = '';
$startusers = $DB->get_records_sql($sql, $params);
$startcandidates = array_filter($startusers, function($u) use ($ainfomod, $information, $modinfo) {
return $ainfomod->is_available($information, false, $u->id, $modinfo);
});
Because $information is an empty string, info_module->is_available() treats it as “no access restrictions”.
Proposed fix
Pass the module’s actual availability rules (including group restrictions) into is_available() by replacing:
- $information = '';
// Apply all “Restriction of access” rules (dates, groups, groupings…).
$information = $cm->availability;
$startusers = $DB->get_records_sql($sql, $params);
$startcandidates = array_filter($startusers, function($u) use ($ainfomod, $information, $modinfo) {
return $ainfomod->is_available($information, false, $u->id, $modinfo);
});
I have applied this patch locally and verified that, after restriction to Group B and running the cron, the students in Group B receive the reengagement email. Please consider merging this change to ensure group restrictions are respected.
Hello,
When an activity is restricted to a specific group, the Reengagement plugin’s cron task still sends emails to managers only—even though students in the target group meet the delay criteria. No student ever receives the reengagement email. Reengagement plugin (version 2023020805) tested on Moodle 4.2 and 4.5.
Steps to reproduce
In a course, create a Reengagement activity and configure “Email user” to send after a delay.
Under “Restriction of access”, add a Group restriction (e.g. “Group B”).
Enroll at least one student in Group B and another student outside Group B. Also enroll a manager.
Wait for the configured delay to elapse and run the cron (php admin/cli/cron.php).
Actual behavior
Only the managers receives the reengagement email.
No student—neither inside nor outside Group B—receives any email.
Expected behavior
The student(s) in Group B should also receive the reengagement email.
Root cause
In mod/reengagement/lib.php, the function reengagement_get_startusers() builds its candidate list by calling:
$information = '';
$startusers = $DB->get_records_sql($sql, $params);
$startcandidates = array_filter($startusers, function($u) use ($ainfomod, $information, $modinfo) {
return $ainfomod->is_available($information, false, $u->id, $modinfo);
});
Because $information is an empty string, info_module->is_available() treats it as “no access restrictions”.
Proposed fix
Pass the module’s actual availability rules (including group restrictions) into is_available() by replacing:
// Apply all “Restriction of access” rules (dates, groups, groupings…).
$information = $cm->availability;
$startusers = $DB->get_records_sql($sql, $params);
$startcandidates = array_filter($startusers, function($u) use ($ainfomod, $information, $modinfo) {
return $ainfomod->is_available($information, false, $u->id, $modinfo);
});
I have applied this patch locally and verified that, after restriction to Group B and running the cron, the students in Group B receive the reengagement email. Please consider merging this change to ensure group restrictions are respected.