Email schedule broken by 4.5.0b patch

[synchro]

Since I installed the 4.5.0b patch, my email schedulers have been broken. The cron job is running successfully, but the scheduler log just records 'failed' with no other info. I've tried removing the output output redirect from the cron job, but that's not generating anything either. Where can I see how/why it's failing?

[ayavilevich]

Check sugarcrm.log and log4php.properties files.

You issue might be the same as mine:
http://www.sugarcrm.com/forums/showthread.php?p=52562

[synchro]

OK, the log says:

SugarCRM - Failing job because we could not get an IMAP connection resource.

I've no idea why it should say that - none of the email settings have been touched, and I'm running the same PHP setup (which has IMAP enabled) as before the upgrade when it worked fine.

[synchro]

When I save settings on a mailbox, I get this message:

No Optimums were saved with your InboundEmail mailbox. Please review the settings

What on earth does that mean?

'Test settings' doesn't seem to work at all, and nor does SSL.

[malcolmh]

We noted the same problem with 4.5, IMAP doesn't seem to worl. We registered a bug, looks like it hasn't been fixed in 4.5b. Currently we are using POP3

[rlbyrd]

FWIW, I "repaired" this issue the same way I've "repaired" this issue in the past with that particular error message.

I went into each group mailbox configuration, re-entered the password, did a test, ensured that then INBOX was the selected monitoring box, and re-saved. Voila, it all works now. Give that a try; but note that you must re-test and re-save every box.

Incidentally, failing to click the "test setup" button resulted, for me, in the "no optimums" error message. Running the test before save eliminated it.

Go figger.

r

[rickcrites]

FWIW, I "repaired" this issue the same way I've "repaired" this issue in the past with that particular error message.

I went into each group mailbox configuration, re-entered the password, did a test, ensured that then INBOX was the selected monitoring box, and re-saved. Voila, it all works now. Give that a try; but note that you must re-test and re-save every box.

Incidentally, failing to click the "test setup" button resulted, for me, in the "no optimums" error message. Running the test before save eliminated it.

Go figger.

r

This same issue has re-appeared for me after upgrading from 4.5.0d to 4.5.0f. I thought I had it fixed, but apparently not.

I have already gone through every one of my 100+ users and reset the name and password. But, I didn't "check" the settings before saving.

Please, can someone point me to a solution that doesn't require that I sit and go through each user AGAIN and "check" the settings before saving? That would be REALLY irritating (and time consuming).

Edit: Here is the error message:

Tue Nov 7 04:40:14 2006,009 [17956] FATAL SugarCRM - SCHEDULERS: could not get an IMAP connection resource for ID [ aa0dfb0f-c5b0-2381-73d6-4548d76f2509 ]. Skipping mailbox [ Avery Parker ].


Thanks,

[sugarchris]

There is a new-ish (released in 4.5.0d or e) Admin utility to repair InboundEmail accounts. Go to Admin -> Repair -> Repair InboundEmail Accounts.

If after running this repair, you still get failed jobs in the Scheduler logger, further info should be available to you in the sugarcrm.log file. It will identify which accounts may have bad credentials (login, password, and/or mailserver). I would hand-fix those as they may have changed (i've learned never to underestimate (l)user error) .

HTH

[rickcrites]

There is a new-ish (released in 4.5.0d or e) Admin utility to repair InboundEmail accounts. Go to Admin -> Repair -> Repair InboundEmail Accounts.

If after running this repair, you still get failed jobs in the Scheduler logger, further info should be available to you in the sugarcrm.log file. It will identify which accounts may have bad credentials (login, password, and/or mailserver). I would hand-fix those as they may have changed (i've learned never to underestimate (l)user error) .

HTH

Thanks Chris,

That repair function was the first thing I tried when I figured out this was happening. That resulted in a list of all 100 users that the log reported as needing to be hand-corrected. That is what I tried to do by going through all 100 and fixing the name and the password. But, I didn't have the data about needing to "test" the corrections to make them stick (as reported in this thread or another I was reading). I may also have screwed things up by changing "personal.<username>" to the user's name: "Firstname Lastname."

At this point, I am pretty discouraged. It seems I am facing another couple of hours of screwing around with this to try to get email going.