AOP 7.8.3 Automatic Status Updates not working

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 :wink: 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?

Oops, sorry, too many threads, I forget who is who : - )

Still you might want to check if the AOP related jobs are running with errors, look in Admin/Schedulers.

Then you can look in the logs (a post on my blog explain that too) and see what error come up that could be related to your issues.

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.

Hi there. Did that, didn’t work. I checked the logs as well, but I don’t see any strange things, I do get

[ERROR] File ‘modules/AOD_Index/Index/Index/segments_5n7’ is not readable. That’s correct - that file doesn’t exist.

I also got a [22335][1][WARN] CaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type

However - when I look for cases.status query’s I do find the SELECT statement, but never an UPDATE statement.

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?

I didn’t change the level of the message, it was “warn” before and it still is.

Fri Apr 21 16:50:02 2017 [23112][1][FATAL] Job f32ce63a-c9c9-4b21-d6b3-58fa1c96999d (Mail check) failed in CRON run

You get just that, not the other warning?

Check that you typed in correctly (in a single line).

If it still breaks the program, try removing the bit about $email->id, maybe that field doesn’t exist.

Checking php_errors.log might give you a more detailed error.

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.

Thanks for your swift reply. I have tried it with multiple new ‘testcases’.

So the steps i follow

  1. sent mail to the inbound cases mail adress
  2. it gets registered as a new case and assigns the contact
  3. sent a mail from the case, set status to Input_pending
  4. receive the mail
  5. sent a reply back
  6. the reply gets registered in the case, but the status is not updated to Update.

This happens to all cases. So everything is working fine. It’s just not updating the status…

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?