Best practice forum (Archived)
Die Forendiskussion wurde entfernt
Hi, Chris
Are any other messages going out e.g. password reset email? I was having a similar issue a while back and it turned out to be the mail server we were using was using 2 IP addresses. One was fine but the other one had some firewall issue and it stopped mail from going out. That might be one to check for if you're not getting any mail at all.
The other one to check is cron and make sure that's running properly.
Failing that, it might be worth double checking there are no exceptions on the program. I might be wrong but I'm pretty sure I setup something silly up when first looking at programs and it created an exception which prevented user enrolment and the enrolment email going out. Don't quote me on that one though as it's a vague memory.
Cheers
Tom
Hi, Chris
The only other thing I can think of, from experience, is the enrolment method. I had an issue with program/certification enrolment timing out with a 500 error and only a couple of emails were getting issued. I got around this by setting the enrolment method in the database to 'cron' instead of 'instant'. This essentially means that enrolment doesn't happen straight away and will take place the next time cron runs. Depending on your requirements and cron timings, this might not be a great solution.
Ours runs every 15 minutes and we didn't mind taking the hit on a small wait time for enrolment to take place. It worked for us, but not sure if this is something you would entertain.
Have you tried checking the PHP errors log, too, to see if there is anything being reported there? There is also a database table that stores messages sent out, so it could be worth checking there to see if anything is being recorded.
This is all from memory, so if you're not comfortable with the above advice, raise a ticket with the support team. They're generally quite good at getting back quickly, but there is a short wait due to timezone difference.
Hope that helps and I would be interested to hear if you resolve it.
Cheers
Tom
Chris the ticketed support recently moved to a new system at http://helpdesk.totaralms.com, I've asked for your account to be checked to make sure you have access, so you may receive an invitation email to set up your account on the new system shortly.
Have you checked in config.php or in mdl_config that you haven't disabled messaging? Check for any of these:
$CFG->messaging=0;
$CFG->noemailever=true;
$CFG->divertallemailsto='a@b.com';
Also check Site Admin->Advanced Features that messaging is turned on "Enable messaging system"
Records of Program messages sent are stored in mdl_prog_messagelog. Program messages are also an instance of totara_message alerts so will also have records in mdl_message and mdl_message_metatdata. If the messages are sent then there will be records in those tables and the problem is likely to be with your email server.
If the records do not exist then something else is going on and maybe your programmer could add some debugging/logging in places like totara/message/messagelib.php function tm_alert_send() and totara/program/program_message.class.php send_message() to see where the point of failure is. Also note a lot of the Program cron functions only run once daily - to change this temporarily look at totara/program/cron.php functions program_hourly_cron() and program_daily_cron() and change the lines
$hourlycron = 60 * 60; // one hour
$dailycron = 60 * 60 * 24; // one day
to
$hourlycron = 0;
$dailycron = 0;
while testing so the Program cron functions will run on every cron run - note this may have serious performance consequences on a production server as the program cron functions are very database-intensive