CRM-16514 Scheduled reminder for event sends email repeatedly

Hi Richard,

I have performed the following steps to replicate the issue, but not able to replicate it.

1) Created an event which has "Event start Date" set in future. (Here, I have set "Event start Date" on May 27, 2015)
2) Added schedule reminder for event. (i.e 5 days before the 'event start date'). Here, the cron job is set to run daily.
3) Registered participant for the event.
4) Executed schedule job "Send Scheduled Reminders", to send reminder email. (Here, reminder was sent)
5) Changed the system date to May 23, 2015
6) Again, executed schedule job "Send Scheduled Reminders", to send reminder email.(No reminder was sent)

Please comment if I'm missing any step here.

Thanks,
Rohan Katkar

This sounds very similar to this problem:
http://civicrm.stackexchange.com/questions/2610/membership-reminders-sending-each-time-scheduled-job-runs-after-4-6-2-upgrade

Is it possible that this only affects scheduled reminders created before an upgrade to 4.6?

Rohan - can you try creating the reminder in 4.5 and then upgrading to see if that's the issue.

Hi,

I've checked the same with upgrade from v4.5 to v4.6 but still not able to replicate it.

1) Installed CiviCRM v4.5 and added schedule reminder for event to send email( i.e 4 days before the event start date).
2) Created an event which has "Event start Date" set in future. (Here, I have set "Event start Date" on May 30, 2015)
3) Registered participant for the event.
4) Upgraded civicrm from v4.5 to v4.6
5) Executed schedule job "Send Scheduled Reminders", to send reminder email. (Here, reminder was sent)
6) Changed the system date to May 27, 2015 (i.e date set to the next day)
7) Again, executed schedule job "Send Scheduled Reminders", to send reminder email.(No reminder was sent).

Thanks,
Rohan Katkar

Richard - A few questions that might help us recreate this:
1. Are the 'unexpected' additional reminders sent to All recipients or just the additional recipients in the selected Group?
2. What "Input Date Format" is the site configured to use (Administer > Localization > Date Formats)
3. Can you check civicrm_action_log table before and after the reminder cron job runs. Expected result is that a new row is inserted for each recipient on initial run. If repeat is not set, and reference date has not changed - then the presence of a civicrm_action_log for for that entity should prevent additional reminders from going out. (details are here: https://issues.civicrm.org/jira/browse/CRM-15728)

Thanks David. I am just away from the office this week but I will take a look next week.

The extra reminders were sent to all recipients.

We are seeing something similar where scheduled reminders for an event are sent multiple times every day once a day, but they are only sent to the additional recipient specified by "Also include" "manual recipients"

Reminders have been set up for 10 events. All follow the same pattern: send to Registered participants, some period of time before the event (the period varies), Also include, one manual recipient (the events administrator).
The number of reminders doubles each day, so today the events administrator received 32 copies from each of 9 events, and 128 from the other one where the reminders were set up a few days before.
The system was upgraded from 4.6.2 to 4.6.3 yesterday before the last set of mails so that has not fixed the problem.
None of the events are within the period when reminders should be sent.

Aidan - It does sound like there's a bug there, but we're not finding a way to recreate so we'll need help debugging on your side.

Can you run the job and dump the value of $query after line 824 in CRM/Core/BAO/ActionSchedule.php sendMailings() - and then run that select query to see what rows are returned, that might help. Also checking civicrm_action_log before and after job run. (see my point #3 in comment above)

I am also having similar issues on my 4.6.4 install. Schedule reminders were set before upgrading 4.4 to 4.6. Participants reported receiving emails repeatedly, even though the event has ended a long ago.

One GUI i found when navigating to Events> Manage Events> Configure> Schedule Reminders, which seems broken. I was able to reproduce on demo site. Screenshot attached. not sure if they are related to this issue.

I don't see any breaks on 46 demo : http://d46.demo.civicrm.org/civicrm/event/manage/reminder?reset=1&action=browse&setTab=1&id=3

Similar thing is happening to me. I have a scheduled reminder set to send an email once 4 hours after an activity is completed. My cron runs every 15 minutes. One user received over 200 emails before we could get it stopped. I've disabled all schedule reminders on my site. This is a really useful feature that I use quite often.

I'm running 4.6.5

We're running into something similar, but with membership renewal reminders. I can duplicate this issue. We set up a membership renewal reminder to run three days before membership expiration (no repeats). It works fine the first time through. Then we update the membership expiration date to a new future date. The next time the renewal reminder is triggered, it starts to send every time the cron job runs.

This started happening when we upgraded to 4.6.2 in our test environment. Until this is rectified, we cannot upgrade our production environment.

We're running on Wordpress.

Submitted a PR https://github.com/civicrm/civicrm-core/pull/6649. Can anyone please verify the fix ?

The fix for this ( https://github.com/civicrm/civicrm-core/pull/6649 ) merged forward into master but produced a conflict with https://github.com/civicrm/civicrm-core/pull/6687 , where the code has been rewritten.

As mentioned in the Github discussion of #6649, the relevant code moved to https://github.com/civicrm/civicrm-core/blob/master/Civi/ActionSchedule/RecipientBuilder.php . From skimming #6649, it seems to deal with the additional contacts, so it might be buildAddlFirstPass() or maybe buildAddlRepeatPass().

Tim, earlier I told Jitendra to send a PR after the Schedule Reminder re-factoring changes got merged in master(not against 4.6). So we merged the PR against 4.6. But unfortunately the commit got merge-forwarded in master.

Anyways the new PR will include the fix as per the new changes (thanks for the hint ) and will revert the conflict arisen.

Thanks

OK, thanks.

Tim Otten It seems Scheduled Reminder is broken on master, as I can't receive any emails whether it's related to activity or events. Some of them I've listed below due to which I'm unable to test the PR against master .

-> js break on the "New Scheduled Reminder" Page. When I select Event Type as "Entity" the select field for "When" doesn't loads itself to "O hours before" -> Event Start Date/Event End Date (http://www.awesomescreenshot.com/image/647576/dc47a0d1bd06a676701c4352acf13935)
-> Just tested the simple Activity reminder

• Created an Activity(Meeting) - Activity Date time (4 hrs from now()).
• Added a Scheduled Reminder for Meeting to send reminder "4 hours before Activity Date time".
• Execute the Schedule Job for Reminder.
• No email was sent.

-> I found that If I select "Also Include" in 'Limit or Add Recipients' field on "New Scheduled Reminder" page and click on save, It automatically gets changed to "Limit to" value.

Tim, can you please check on this.

The "New Scheduled Reminder" screen doesn't show any errors for me. I think that screen underwent some work during the intervening period, so not too surprised by that.

I've gone ahead and forward-ported the 'reminder.id IS NULL' constraint: https://github.com/civicrm/civicrm-core/pull/7668

In some manual testing, scheduled reminders for activities did work in normal usage (Recipient=>Activity Assignee)... but not in the use-case of "Choose Recipient(s)". And... you might wonder... how much test coverage is there for "Choose Recipient(s)"? Drum roll.... ZERO! Tada! There's no test, and it's broken. Go figure. (I will direct my shouting somewhere outside JIRA.)

I've added a test case which reproduces the "Choose Recipient(s)" problem in https://github.com/civicrm/civicrm-core/commit/79d51200163da9a32b3e7b79ea3fd0a5418030f3

(EDIT) I may misunderstand the meaning of "Limit To=>Choose Recipient(s)", and the UI/layout actually suggests different behavior for "Activity" and for other records. In which case the test is less broken (but still broken), and it just means we have explicitly test more edge-cases....

The original patch has been merged/forward-ported.

During testing, other issues were identified and filed as CRM-17895 and CRM-17896.