-
Notifications
You must be signed in to change notification settings - Fork 40
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
Comments
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! |
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? |
Hi Dan, Steps to recreate are pretty simple:
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. |
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! |
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! |
Thanks! |
After a sh*tload of Emails send out to users, I'm pretty sure the following problem is occuring:
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.
The text was updated successfully, but these errors were encountered: