Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: After deleting reengagement activity, mails are still being sent #49

Closed
Richardvi opened this issue Jan 14, 2019 · 6 comments
Closed

Comments

@Richardvi
Copy link

After a sh*tload of Emails send out to users, I'm pretty sure the following problem is occuring:

  1. If you add a reengagement activity, set it up, then change your mind and delete it... the mdl_reengagement_inprogress table is still being populated with tasks and the emails are still being send out.
  2. If you change your reengagement settings, the same error occurs: the old corresponding mdl_reengagement_inprogress records still exist and will be added together with the new setup.

We have students complaining about reengagement mails. When we asked to forward these mails, we could see by the subject that these mails belong to a reengagement activity that had been deleted a long time ago.

I also noticed that the reengagement activity is not going to the course recyclebin. So is it properly deleted?

I solved this by deleting the reengagement activity in the MySQL database mdl_reengagement table.

@Richardvi Richardvi changed the title After deleting reengagement activity, mails are still being sent BUG: After deleting reengagement activity, mails are still being sent Jan 14, 2019
@danmarsden
Copy link
Member

Deleting a reengagement activity will always delete the in progress records before deleting the actual reengagement. The cron process responsible for sending e-mail also first gets a list of re-engagments in the site from the reengagements table and then for each current reengagment it will check to send the e-mails. So... I can't see how your first item can occur. Can you please provide more information/steps to reproduce this?

regarding your 2nd point - yes, I think I've seen something like this occur - the in progress records generated after the reengagment have been set up may not match the same rules - especially if you change activity restriction details etc. We probably need to look at a way to make it clear to the teacher what will happen when they change settings, or implement a way to clear out the in-progress records for a current reengagement when the settings change.

Feel free to help us work on this!
thanks.

@danmarsden
Copy link
Member

I don't suppose you have a testing environment that has an old version of your production database and is sending out these e-mails?

@Richardvi
Copy link
Author

Hi Dan,
We do have a test environment but I'm sure that's not sending the emails. The test environment did not hold the reengagement activities that created the problem.

Steps to recreate are pretty simple:

  1. Create a reengagement activity and set it up

  2. Wait for the cron to run (mine runs every 2 minutes)

  3. Check in table mdl_reengagement_inprogress is populated.

  4. Delete your reengagement activity

  5. Check your course recycle bin: it will not be there

  6. Wait for the cron to run or run it manually

  7. Check table mdl_reengagement_inprogress, in my Moodle (3.5.2) it is still populated

  8. Check table mdl_reengagement, it still has your reengagement activity

Dan, just a suggestion: I think this activity would be a lot clearer if, when you view the activity, it shows exactly which user will get notified. And when. And if possible: for how many times. And the end date of notification.

Also: make sure that the users who will not be notified (for example when they turned in an assignment you are monitoring) are recognizable in the list. This way a teacher who sets it up will understand which user is notified.

Right now, in the notification-list are also users that have already completed the assignment you are monitoring. They even have a date on which they will be notified, but they should not be notified because they have already completed the activity you are monitoring.

@danmarsden
Copy link
Member

I suspect you have an issue on your site with ad-hoc tasks which are responsible for running the module deletion process. When a module is deleted the "deletioninprogress" flag is set in the course_modules table and then the ad-hoc task should do the actual deletion.

We can look at adding a check for this field prior to sending any e-mails and exclude any modules that are currently being deleted - but you should check to see why this ad-hoc task isn't running on your site because it could cause you other problems too..

Yeah - the list of users displayed when viewing the activity isn't great and it is definitely something that could be improved. Feel free to help us work on this. (funding and pull requests always welcome.)

thanks!

@danmarsden
Copy link
Member

I've just dropped a patch into all branches 3.2 and higher and Totara 10 and higher which is where the deletioninprogress db change landed. Hopefully it helps!

@Richardvi
Copy link
Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants