Problem/Motivation
We are using recurring events registration and recurring events registration reminders submodules. I have noted two issues and I'm not sure why we're seeing what we're seeing:
1. An event series is created with registration reminders turned on. Next, an event instance is created. Until the event series' registration reminders schedule is changed, the event instance's reminder_date stays null.
2. If the event series' reminder registration schedule is changed (e.g. from '1 day' to '2 days'), ALL event instances have their 'reminder_sent' value set to 'NULL' which means past events will receive reminder emails.
Steps to reproduce
- Create a new event series
- Enable regisration, and registration reminders.
- Create an event instance
- Note that the table 'eventinstance_field_data' has 'reminder_date' equal to null
- Update the event series and change the registration reminder schedule
- Note that 'eventinstance_field_data' now has 'reminder_date' set, but for ALL instances, even those in the past, 'reminder_sent' is null.
Proposed resolution
I'm not sure how best to approach the first issue. The second is fairly straightforward - it should validate against the event end date before setting the 'reminder_sent' to null.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | recurring-event-reminders--remind-date.patch | 3.72 KB | ll66382 |
Comments
Comment #2
ll66382 commentedThanks your clear write up and for the report @phillamb168. I can reproduce the same, although it sounds like you found workarounds.
Here're my notes to help writing a pull request. I should be able to prepare one shortly.
1) Clicking Add instance on series creates an instance with
reminder_dateempty2) When the series
reminder_datechanges, Instances'reminder_sentis emptied3) If Series dates changes but reminder options did not, instances are recreated without a
reminder_date(note it's expected Instances are recreated when series dates change)To clarify one point, reminders for past events shouldn't get sent - I see a check for that - but can see how clearing
reminder_sentin #2 would mean people could be reminded more than once.Comment #3
ll66382 commentedI've attached a patch that address the issues and is quite minimal. But
recurring_eventsis heavily relied on by some sites with large numbers of events and traffic, so it'd be helpful getting another maintainer's reviewHere a summary of the changes, which are within
recurring_Events_registration:I'll mark this as Needs review.
Comment #4
ll66382 commentedComment #5
camilo.escobar commentedHello @ll66382 and @phillamb168.
I understand the two issues raised here, although my comment will focus exclusively on issue #2.
The functionality for sending multiple reminders for an event (by updating the reminder settings in an event series - for example, initially scheduling a reminder for "1 month before" and later adding a new reminder for "1 day before") was introduced in #3283237.
While this feature is valuable, an important detail was overlooked: only future event instances should be marked for sending new reminders. That is exactly what issue #2 here reports, and I agree it makes total sense.
However, I believe the solution implemented for issue #2 in the provided patch is incorrect.
In the original code,
recurring_events_reminders_eventseries_updateproperly checked that reminder settings had actually changed by comparingreminder_amountandreminder_unitsbetween the original and the updated entity:The patch removes this evaluation, which means that any change to the event series - or even simply saving it without modifications - will update the
reminder_dateandreminder_sentvalues for all event instances, marking them to send reminders. This creates a new and more severe bug than the one originally reported.The correct approach should be to retain the check for changes in the reminder settings, and then update
reminder_dateand resetreminder_sent(NULL) only for instances with future dates.For that reason, I have created a separate issue specifically describing and resolving #2: Issue 3545215.
Recommendations for this issue:
Comment #6
camilo.escobar commented