I recently migrated my SCRM 7.13.0 to another host. All was going well until I noticed an error appearing in error.log
I eventually resorted to deleting the inbound accounts and now only have a ‘system’ inbound account setup. However I now have some strange changes in behaviours.
No.1
I have a custom scheduledtask that sends birthday emails every morning using SugarPHPMailer(). This previously (for years) would add an entry in the History for the contact after sending the email. For some reason it no longer adds the entry in History and I cannot figure out why!
Can anyone throw light on this please?
Can anyone please help me with the cause of errors shown below…
Suitecrm.log
Tue May 16 00:15:04 2023 [2508669][1][FATAL] log call at: modules/EmailMan/tpls/config.tpl:464 - styleChecked is not set
Tue May 16 00:21:15 2023 [2526445][1][FATAL] DEBUG: token already sent
Tue May 16 00:41:45 2023 [2594821][1][FATAL] log call at: modules/EmailMan/tpls/config.tpl:464 - styleChecked is not set
Tue May 16 00:57:04 2023 [2611741][6f9b3212-07d2-412a-a6fc-637043b5e306][FATAL] DEBUG: token already sent
Thank you for your help on this. I have checked all the compatibilities and everything is ok.
The No. 2 error seems to have settled down and does not seem to be an issue. My main problem right now is that the scheduled emails don’t get recorded in history.
If I click a contacts email, and send an email (using my birthday email template) manually using SCRM compose email window etc. Then it sends and records in the history as expected. No problem!
If however, an email (using the email template) is sent from the scheduler, it sends the email BUT it does NOT record the event in the history, which it did in the past as can be seen from image in previous post.
I have only setup outbound mail. Nothing in the inbound settings.
The code (in part) in the scheduled task that sends the mail is;
require_once "include/SugarPHPMailer.php";
$mailer = new SugarPHPMailer();
$mailer->prepForOutbound();
$mailer->setMailerForSystem();
$admin = new Administration();
$admin->retrieveSettings();
$admin->settings['notify_fromname'];
$mailer->From = $admin->settings['notify_fromaddress'];
$mailer->FromName = $admin->settings['notify_fromname'];
$mailer->IsHTML(true);
$emailAddress = new sugarEmailAddress;
$primary = $emailAddress->getPrimaryAddress($contact);
if (!empty($primary)) { // if contact has an email address
$mailer->AddAddress($primary);
$mailer->AddBCC('me@blabla.com');
$mailer->Send();
}
So, I’m am a little stumped as to why this is not recording in History anymore. I have gone over it and over it. Any ideas as to what I might be missing is appreciated. Happy to share the full code if required.
To make it appear in history, a relationship must be created. Either the code to make it isn’t there, never existed, or (more likely) is getting stopped by a bug
Don’t your logs show something suspicious during that operation? Something that could serve as a clue?
History , if I’m not mistaken is stored in the ‘Notes’ table. One-to-many relationships exist between contacts and notes and also between Accounts and notes.
In any case this obviously works because if I manually send the birthday template email from the contact email field and using the ‘compose email’ etc. The email is recorded in the history.
Unfortunately, no logs show up in error_log or in suitecrm.log
Just to be clear…
I assume that this recording in the ‘History’ of outgoing emails is already coded in Suitecrm and should just happen. There isn’t a box I should have ticked somewhere?
This is frustrating knowing that it worked before.
History subpanel includes (aggregates) more modules, not just Notes, also Emails, and maybe some other module, I don’t recall.
The code that SuiteCRM uses is not the same in the two cases you describe. One version of the code adds the relationship, the other one (from the Scheduler) does not…
There might be good reasons for this - perhaps somebody decided that it ws not good to pollute Histories with Campaign emails, since it can quickly get excessive - and there are other mechanisms to track Campaigns.
This might help you work around it, although I am not sure it is the same issue.
