I have a problem with AOP after upgrading to 7.8.3 - the case status updating doesnât work anymore.
I tried everything, quick repair and such, but itâs still not working⌠So when someone sends a reply to a case, normally it would switch the status from Pending_input to Update. The same when a case is closed - if someone sends a mail to a closed case, the case is being reopened and the status is switched to Update.
Does anyone have any idea? Iâm running Debian 7/PHP 5.6.29-0+deb8u1 on nginx/1.10.2. Thanks!
Perhaps your Scheduler jobs arenât running, please check your logs for cron related messages.
The Release Notes for 7.8.3 mention a new mechanism to check which user cron is running under. If that is your problem, you can read details about it in my blog below, post about Scheduler jobs (the bit about cron_allowed_users).
Hi there, no you already helped me with that Cause I first had the problem that it didnât create any cases at all - that had to do with the cron job change. So thatâs not this. Any other suggestions?
Oh, and I forgot an important piece of advice, do this first.
When you fixed you cron user you prevented future problems, but you didnât solve old problems. You need to reapply correct permissions to your directories, because there might be files with incorrect permissions because of when the cron jobs were running with a different user. If everything goes well, you only have to fix permissions this one last time, then everything should stay stable.
The AOD error seems to be either a permissions problem (file cannot be read), or a corrupted Index (happens sometimes). You can search the forums on how to rebuild AOD Indexes.
Thereâs a Scheduler job called âAOP Check Inbound Mailboxesâ does it show as running correctly, without errors, in Admin /Schedulers?
The second error seems quite related to your problem. You can get more info by going into modules/AOP_Case_Updates/CaseUpdatesHook.php and editing line 224 to look like this:
$GLOBALS[âlogâ]->warn(âCaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type. Intent: $email->intent ParentType: $email->parent_type Id: $email->idâ);
(note the double quotes so that variables get evaluated)
Then get that to run again and check the results in the log.
Hi there, fixed the AOD_Index issue by deleting the index folder and truncate the AOS_Index and AOS_Indexevent in the database.
For the AOP issue - AOP_Poll works just fine, no errors in Admin/Schedulers, runs every ten minutes, if there are new mails it creates new cases, if there are replies on cases, it puts them in the right case, itâs just simply not updating the status.
So, when I wanne try your tip, on which level do you want me to put the log on?
There was an error because I just copy pasted your suggestion without looking really good at it - you typed per accident $GLOBALS->warn instead of $GLOBALS[âlogâ]->warn. So for anyone else trying this - make sure you add [âlogâ]
Now I get this
Sun Apr 23 12:00:02 2017 [21222][1][WARN] CaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type. Intent: createcase ParentType: Id: 82844b1c-671a-d6f1-81f6-58fc7bbaa687
No, the reason my command appeared incorrect was because I should have included it on CODE tags here on the forums, or else the brackets and their contents are removed.
Thatâs the same reason why your post above looks weird.
So the command should be
$GLOBALS['log']->warn("CaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type. Intent: $email->intent ParentType: $email->parent_type Id: $email->id");
Yeah I already made it look like that and then the error is
Sun Apr 23 12:00:02 2017 [21222][1][WARN] CaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type. Intent: createcase ParentType: Id: 82844b1c-671a-d6f1-81f6-58fc7bbaa687
And about your results: the parentType field isnât filled, for some reason. Normally it should be âCasesâ if the email is related to a Case.
Maybe itâs a bug, maybe itâs just something that got corrupted in a specific line in your database.
Can you try with a new case, a new email, created just for this test? And record the steps you take exactly, because if thereâs still an error I can try and reproduce it here or maybe report as a bug.
Iâm afraid I donât know enough about using Cases with email to really help here. Maybe you should open a new Issue on Github providing your steps to reproduce the problem, and also our diagnosis here with the enhanced log message. That should be enough for track down what is wrong with the codeâŚ
Hi there. Well thanks for trying to help! Do you think it might be helpful to remove the whole suitecrm directory and upload the new one, where I config it to use the current database? Then we could narrow down if itâs a code issue (perhaps an upload file error with the upgrade) or if itâs a database error.
Ideally you would try to reproduce the bug on a fresh installation of SuiteCRM to rule out any particular problem in your install.
Normally this is easily achieved by just going in to one of the SuiteCRM demos that are available online, and try the âsteps to reproduceâ there. But in your case the test involves Email configurations which might be hard to achieve in a public demo.
So if you are capable and willing of trying this on a new local install, that would be perfect for the purposes of the bug report. and if you realize it works well on a fresh install, then you might try and figure out what is different about your current install that is breaking thingsâŚ
I did a whole fresh install. Not working either - it creates the cases, sends the mails but itâs not updating the status. Again, on this whole fresh installation (fresh database as well), with your CaseUpdatesHook.php edit on line 224, the error is
Sun Apr 23 19:49:02 2017 [24336][1][DEBUG] Hook called: Emails::after_save
Sun Apr 23 19:49:02 2017 [24336][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Sun Apr 23 19:49:02 2017 [24336][1][WARN] CaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type. Intent: createcase ParentType: Id: 788c0bfc-28c5-30ef-1c90-58fce90e7fce
I canât find any warns in the Hook called: AOD_IndexEvent::before_save. So it does seem like a bug in 7.8.3. How can I submit it to GitHub?