Suitecrm: Case Updates Threaded not Saving

[Glen206]

when clicking on save to enter a new case update, The screen shows a dialogue box "please wait" after the dialogue box disappears. the update is not saved. and NO update thread is created.

using the chrome inspection tool the following errors show up as soon as you click in the save button.

Expected Behavior

Update is saved and an update thread is created.

Steps to Reproduce

I tried to reproduce this in on the SuiteCRM demo site but the case updates are working as expected.

1. open cases module
2. View a current case
3. Type an update in the "Case Updates Threaded" text area
4. Click Save

here is a video: http://screencast.com/t/Ebz1su7gz7

Your Environment

SuiteCRM 7.7.4
Chrome Version Version 52.0.2743.116 m (64-bit)
MySQL, PHP 5.6.25
CentOS 7 (64-bit)

[shogunpol]

The issue has been tested on recent version of SuiteCRM(7.7.4), and not appear,
Can you gives us any more details, for example; do you do this through https conection, anything in apache log, suitecrm log?.
@Glen206 , thanks for raise this issue.

[emcrobert]

I'm not sure if it's been fixed now, but I know this was an issue in the past and I created a pull request to fix it:

https://github.com/salesagility/SuiteCRM/pull/1895

From my experience it was only a problem when you were using Suite P as the theme

[pgorod]

I have the same problem. Let me quote a forum post I wrote only yesterday:

I have this same problem, threaded updates are not saving. I tried both Edge and Firefox, both themes SuiteR and SuiteP. I am on the latest version of SuiteCRM (7.7.4) and I don't have any customizations on the Cases module.

I checked the database (table aop_case_updates) and the information is not getting saved there.

I don't see any browser console errors; I don't have anything looking relevant in the logs...

I don't think it's a browser problem, though, because I tried an online SuiteCRM demo (softaculous) and the threaded updates work fine there with my normal browser which is Firefox.

How could I further debug this?

[pgorod]

I just tried manually applying the changes in the fix #1895 and it didn't solve my issue in SuiteP theme.

This is consistent with the fact that the problem is also happening in SuiteR, so it must be a different problem.

I'd be glad to provide more info if I only knew what could give us a clue into this...

[ijdavie]

@pgorod, @Glen206 anything that can give us a clue to what is causing this I guess, anything in the logs, console log etc.

[mdauphin]

I have the same problem with 7.6.6
In Firefox log I have POST request with

record=37bd7e56-d0f2-d64e-804a-57ecd7bf2ffc
module=Cases
return_module=Cases
action=Save
return_id=37bd7e56-d0f2-d64e-804a-57ecd7bf2ffc
return_action=DetailView
relate_to=Cases
relate_id=37bd7e56-d0f2-d64e-804a-57ecd7bf2ffc
offset=1
update_text=test
internal

And SuiteCRM log:

Thu Sep 29 13:03:14 2016 [14373][65ff25ef-e3b3-151b-a258-43216748980d][ERROR] Unable to load custom logic file: custom/modules/Cases/CasesJjwg_MapsLogicHook.php
Thu Sep 29 13:03:14 2016 [14373][65ff25ef-e3b3-151b-a258-43216748980d][ERROR] Unable to load custom logic file: custom/modules/Cases/CasesJjwg_MapsLogicHook.php
Thu Sep 29 13:03:14 2016 [14373][65ff25ef-e3b3-151b-a258-43216748980d][ERROR] Unable to load custom logic file: custom/modules/Cases/CasesJjwg_MapsLogicHook.php
Thu Sep 29 13:03:14 2016 [14373][65ff25ef-e3b3-151b-a258-43216748980d][ERROR] Unable to load custom logic file: custom/include/social/hooks.php
Thu Sep 29 13:03:15 2016 [14373][65ff25ef-e3b3-151b-a258-43216748980d][ERROR] convert: Conversion of 2016-09-29 16:00 from Y-m-d H:i:s to Y-m-d H:i failed

[pgorod]

@ijdavie I've been stepping through the code, debugging this issue and I'm making some progress. I believe my problem is simply that this hook is not firing:

$hook_array['before_save'][] = Array(10, 'Save case updates', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'saveUpdate');

But that code comes, I believe, from an outdated file that somehow is still present in my system: custom/modules/Cases/logic_hooks.php. That's not part of the current codebase for my version (7.7.5).

I've had previous problems arising from that upgrade when all the SalesAgility modules were moved away from the custom directory. Something didn't go right in that upgrade (and it seems I'm not the only one with this problem...).

Now, I just need a little help fixing it: searching the official code here on Github, I see that there is no hook definition (like the one above) in the code. It is now done through the installer, I think the installer creates a new file with the hook definitions. Can somebody please tell me where that is, so I can check it? Or even paste here the contents of that file in a working installation of v7.7?

Thanks!

[pgorod]

_Bump_, can somebody please tell me where the hook file is created by the installer (probably modules/cases/logic_hooks.php and paste the correct contents of that file here (for version 7.7)? Thanks.

[kyriakoy]

Same problem with our installation, with the same output to log
[ERROR] Unable to load custom logic file: custom/modules/Cases/CasesJjwg_MapsLogicHook.php

In our case using 7.7.4 we had the above problem but when we edit the case and then insert an update was working. After apply 7.7.6 we had the same error.log but this time is not saving the case update.

[pgorod]

I had to create a brand new install to check how the hooks are getting created by the installer.

They are in custom/modules/Cases/logic_hooks.php, and the contents on a clean 7.7.6 install are as follows:

<?php
// Do not store anything in this file that is not part of the array or the hook version.  This file will
// be automatically rebuilt in the future.
 $hook_version = 1;
$hook_array = Array();
// position, file, function
$hook_array['before_save'] = Array();
$hook_array['before_save'][] = Array(1, 'Cases push feed', 'modules/Cases/SugarFeeds/CaseFeed.php','CaseFeed', 'pushFeed');
$hook_array['before_save'][] = Array(10, 'Save case updates', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'saveUpdate');
$hook_array['before_save'][] = Array(11, 'Save case events', 'modules/AOP_Case_Events/CaseEventsHook.php','CaseEventsHook', 'saveUpdate');
$hook_array['before_save'][] = Array(12, 'Case closure prep', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'closureNotifyPrep');
$hook_array['before_save'][] = Array(77, 'updateGeocodeInfo', 'modules/Cases/CasesJjwg_MapsLogicHook.php','CasesJjwg_MapsLogicHook', 'updateGeocodeInfo');
$hook_array['after_save'] = Array();
$hook_array['after_save'][] = Array(10, 'Send contact case closure email', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'closureNotify');
$hook_array['after_save'][] = Array(77, 'updateRelatedMeetingsGeocodeInfo', 'modules/Cases/CasesJjwg_MapsLogicHook.php','CasesJjwg_MapsLogicHook', 'updateRelatedMeetingsGeocodeInfo');
$hook_array['after_relationship_add'] = Array();
$hook_array['after_relationship_add'][] = Array(9, 'Assign account', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'assignAccount');
$hook_array['after_relationship_add'][] = Array(10, 'Send contact case email', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'creationNotify');
$hook_array['after_relationship_add'][] = Array(77, 'addRelationship', 'modules/Cases/CasesJjwg_MapsLogicHook.php','CasesJjwg_MapsLogicHook', 'addRelationship');
$hook_array['after_retrieve'] = Array();
$hook_array['after_retrieve'][] = Array(10, 'Filter HTML', 'modules/AOP_Case_Updates/CaseUpdatesHook.php','CaseUpdatesHook', 'filterHTML');
$hook_array['after_relationship_delete'] = Array();
$hook_array['after_relationship_delete'][] = Array(77, 'deleteRelationship', 'modules/Cases/CasesJjwg_MapsLogicHook.php','CasesJjwg_MapsLogicHook', 'deleteRelationship');

I don't think those hooks should be defined under the custom directory once the rest of these modules has been moved elsewhere. This is confusing and makes migrations difficult, because we need to cherry-pick stuff from the custom directory that we need to move over to a new install. This is compounded by the fact that we can't check which are the standard files on Github because they are only created at install time. I might open a new issue about that.

But first I will go check that correcting the hooks solves the bug on my production system, and then I'll report back here...

[pgorod]

Yes, I confirm this solves the bug. So...

1. To people experiencing the problem: check that your SaveUpdate hook is firing. See my post above for the correct location and contents of the logic_hooks.php file. (Fixing this works immediately, no Repair and Rebuild necessary).
2. To @shogunpol or @emcrobert or @ijdavie: I recommend just closing this bug. It is diagnosed, a solution is explained, and I suppose it only happens with specific migration/upgrade paths. I will create another issue specifically questioning the location of these files, but it's an installer issue.

[shogunpol]

@Glen206 - Thank you for highlighting this issue, however, this is a duplicate of issue #2015. This is issue will be closed, please follow the original issue.

[Glen206]

@pgorod,

Are you saying that you moved the logic_hooks.php file from custom/modules/cases/ to modules/cases?

[pgorod]

@Glen206 no, they are created by the installer under custom and that's where they should be (with the content as detailed in my post above).

But my bug was caused by not having them there, because when I migrated my customizations I accidentally removed them, thinking only my own customizations should be in the custom folder. But some parts of SuiteCRM default install still go in there, I'm afraid.

There should be no logic hooks file in modules/Cases/.

[Glen206]

Thank You. I verified that my directory, custom/modules/cases/logic_hook.php exists and matches what you have above. Looks like I have a different issue. ;-(

[pgorod]

Ok. Still, I would make sure that the hook is, in fact, firing.

Check that you have this file:
modules/AOP_Case_Updates/CaseUpdatesHook.php
and that is has a class called CaseUpdatesHook with a method called saveUpdate.

Then, inside that method, add a command to log something right at the first line, and check that your logs show that string when you update a case with the "threaded" entry box.

[Glen206]

@pgorod, while looking into modules/AOP_Case_Updates/CaseUpdatesHook.php, I was promted to look at the AOP settings and found that it was not turned on.

Once I turned on AOP I was able to update.(almost)

When I go to save an update the dialogue box does not go away. So I have to manually close it, Then if i hit refresh, the thread appears in the history above.

i'm making some progress. If this is a feature setting then, there should be a warning in cases that lets you know that AOP needs to me setup first prior to cases working properly. Again this may just be my SuiteCRM Instance.

[pgorod]

I'm glad you're making progress. Try to make sure all the pieces are in place.

On my install custom/modules/Cases/logic_hook.php is the ONLY thing that I have under custom/modules/Cases.

I don't have any folders called custom/modules/AOP*

Then you can check the contents of these folders against the Github repository itself:

• modules/Cases
• modules/AOP_Case_Updates
• modules/AOP_Case_Events

[pgorod]

If you set your logging level to DEBUG, you can see it coming up in the logs when you add an update.

In my system, this is what an update looks like using this command to grep the log:

cat suitecrm.log | grep -i case | grep -i hook

Tue Jan 17 14:57:34 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:34 2017 [57347][1][DEBUG] Including module specific hook file for custom/modules/Cases
Tue Jan 17 14:57:34 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:34 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:34 2017 [57347][1][DEBUG] Hook called: Cases::before_relationship_add
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_relationship_add
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CasesJjwg_MapsLogicHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_save
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseFeed without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::before_save
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::after_save
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseEventsHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CasesJjwg_MapsLogicHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_save
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CasesJjwg_MapsLogicHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Including module specific hook file for custom/modules/Cases
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_ui_frame
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Including module specific hook file for custom/modules/Cases
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Including module specific hook file for custom/modules/Cases
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:35 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::before_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: AOP_Case_Updates::after_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::after_ui_frame
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::before_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Hook called: Cases::after_retrieve
Tue Jan 17 14:57:36 2017 [57347][1][DEBUG] Creating new instance of hook class CaseUpdatesHook without parameters

I have no idea why there are so many hooks firing, but it works...

If the hook doesn't fire, there are detailed instructions on my post above (14 days ago) on how to check it's definition.

[hemanthvaddi]

@Glen206
You said "When I go to save an update the dialogue box does not go away. So I have to manually close it, Then if i hit refresh, the thread appears in the history above."

I seem to have the same problem. Did you fix this issue?

[chinboy11]

Having this same issue. Any luck?
Version 7.8.2
Sugar Version 6.5.24 (Build 509)

cases is not very useful without this feature...

[hemanthvaddi]

It was an HTML panel id issue for me. When we click on the update button, it calls an ajax function in Case_Updates.php file and updates the UI. I had different IDs. Check if the CRM page has same panel ID as of your code.

[fcorluka]

This has to be problem with upgrade. I did upgrade from 7.4.3 do 7.8.8 and this does not work.
I tried editing logic hooks but no luck.

I assume that for us with this issue there is no other way but go file by file and see what is changed in wrong way.

[pgorod]

@fcorluka yes, the bug seems to be real, but it's probably in the upgrade-script, so there is nothing to fix in SuiteCRM itself...

My posts above should give you sufficient info to work things out, but it does require some hard work. :-(

[fcorluka]

Thank you @pgorod for instructions, but it is not working. I tried looking all differences between those modules (Case, AOP_Case_Updates, AOP_Case_Events) and there is no difference between my updated code and fresh installation (beside of mine customization).
Is anyone having some luck with this?

[pgorod]

Can you try this technique to check which files SuiteCRM is looking for?

https://pgorod.github.io/Audit-File-Accesses/

That should give you an inside perspective on things, to check whether your hook definitions are getting loaded, and then whether your actual hook code is getting loaded.

This is basically all you should need to get working:

Check that you have this file:
modules/AOP_Case_Updates/CaseUpdatesHook.php
and that is has a class called CaseUpdatesHook with a method called saveUpdate.

And the Audit method described in that post should let you check if it's really happening or not.

[fcorluka]

Thank you for help, btw. nice article; I will try this method.

About that file and function. Both exist and run, I went through that function with debbuger, so I know it is "alive".
I will try with your method to see what is happening, and give feedback.

[pgorod]

If the hook is running, then you have a different problem, not the one on this thread.

What exactly are your symptoms? And do you have any errors in your log, or in the Browser's Web console?

[fcorluka]

I belive I am doomed with this. So, from yesterday afternon I can't save update text. Didn't make any changes, git log is the same, but just won't save.

[EDIT]
Save problem was with AOP settings. It is working now.

Only error is in browser console:
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help http://xhr.spec.whatwg.org/
sugar_grp1_jquery.js:4:14158
Attempt to set a forbidden header was denied: Content-length
index.php:1093:4
Attempt to set a forbidden header was denied: Connection
index.php:1094:4
This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!

[pgorod]

@fcorluka what is your PHP version? Is it compatible with your version of SuiteCRM?

[fcorluka]

I'm on PHP 5.6, but tried with 7.1.11 and nothing.

[patrickwilson82]

I'm having this problem as well. When I check CaseUpdatesHook file for the class CaseUpdatesHook, this is what I have. Is this configured correctly?

class CaseUpdatesHook {
$GLOBALS['log']->warn("CaseUpdatesHook: saveEmailUpdate: Not a create case or wrong parent type");
$GLOBALS['log']->warn("CaseUpdatesHook: saveEmailUpdate No parent id");
$GLOBALS['log']->warn("CaseUpdatesHook: saveEmailUpdate cases already set");
$GLOBALS['log']->warn("CaseUpdatesHook: sendClosureEmail called");
$GLOBALS['log']->warn("CaseUpdatesHook: sendClosureEmail template is empty");
$GLOBALS['log']->info("CaseUpdatesHook: Could not send email: " . $mailer->ErrorInfo);
$GLOBALS['log']->warn("CaseUpdatesHook: sendCreationEmail template is empty");
$GLOBALS['log']->info("CaseUpdatesHook: Could not send email: " . $mailer->ErrorInfo);

[pgorod]

That looks quite strange. Exactly which file is this in?

And you went looking for it because you saw it referenced somewhere. Exactly where is this file referenced, and how?

[patrickwilson82]

This is in the file:
var/www/html/suitecrm/modules/AOP_Case_Updates/CaseUpdatesHook.php

From: pgorod [mailto:[email protected]]
Sent: Tuesday, December 5, 2017 11:50 AM
To: salesagility/SuiteCRM [e-mail]
Cc: patrickwilson82 [e-mail]; Comment <
[email protected]>
Subject: Re: [salesagility/SuiteCRM] Case Updates Threaded not Saving
(#2237)

That looks quite strange. Exactly which file is this in?

And you went looking for it because you saw it referenced somewhere.
Exactly where is this file referenced, and how?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/salesagility/SuiteCRM/issues/2237#issuecomment-349366025,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agqw0uy4tJAftTxyQA9hWV4AxR5EK2YYks5s9XQ4gaJpZM4J-Uu7
.

[pgorod]

Let me give you a couple of Github tips first:

When posting code, start with backticks and the word php
```php
then the code goes here
then end with
```

Second, when answering from email, avoid keeping all that extra quoted text with the post you're answering to. You can edit your post now to remove that.

And now, about your issue: compare with the official code here:
https://github.com/salesagility/SuiteCRM/blob/master/modules/AOP_Case_Updates/CaseUpdatesHook.php

[fcorluka]

Hi guys, so I just solved this issue.

Problem is next:
file: /modules/AOP_Case_Updates/Case_Updates.php
line: 120
''' html
$("#LBL_AOP_CASE_UPDATES").load("index.php?module=Cases&action=DetailView&record="+record + " #LBL_AOP_CASE_UPDATES", function(){
'''
This "#LBL_AOP_CASE_UPDATES" is not in /custom -> detailviewdefs.php if you have an older version of CRM updated to new one.
So to make it work, open /custom/modules/Cases/metadata/detailviewdefs.php; and find your panel definition and change it to LBL_AOP_CASE_UPDATES.

Hope this help someone.

[pgorod]

@fcorluka you deserve a medal for this one! 🥇

Can you tell us exactly which version of SuiteCRM you upgraded from, and which version you upgraded to?

@patrickwilson82 can you please confirm if this works for you?

[patrickwilson82]

I haven’t really had a chance to test it out yet. We may be looking at
re-doing our current crm anyways. I’ll let you know if I’m still having
issues. Thanks!

[fcorluka]

I had crm on 7.4.3 and updated to 7.6.10, and then to 7.8.8.

[pgorod]

@fcorluka I'm trying to understand exactly which upgrade script is breaking the feature, and how exactly it's breaking.

If you simply remove /custom/modules/Cases/metadata/detailviewdefs.php from your system, so it picks up whatever is in the main file, modules/Cases/metadata/detailviewdefs.php, does everything work well for you?

[fcorluka]

Hi @pgorod,

I tried removing file from custom, and it did work correctly.
I belive the problem is in next:

• update script works only on /modules /*
• any change in custom is ignored
• I have customized Cases module
• update script hasn't changed my custom files and so I had this problem (+ I corrected paths in Cases logic_hooks.php file)

[pgorod]

There is one particular upgrade script somewhere around 7.5, I think, that does a lot of work on the custom directory, moving all the SalesAgility "Advanced Open" modules out of the custom directory, into the main modules directory.

That script should have removed your custom file, and left everything working, yet it didn't. I believe the reason for this could be that you say "I have customized Cases module", probably the script just left a message for you in the logs, that you didn't see, explaining it couldn't remove that file because you had customized it...

[fcorluka]

That seems logical.
Problem remains for any further upgrade because I would like to save my custom view.
Problem if even bigger if I have 5-6 modules customized and all are gone, or have problem like this (layout is OK but no functionality).

[pgorod]

You should be able to start a fresh customization by copying the new file from modules/Cases/metadata/detailviewdefs.php to a new /custom/modules/Cases/metadata/detailviewdefs.php and then transfer whatever you customized, manually, into that file.

You're basically merging whatever SuiteCRM updated in that file, with whatever you customized in your system.

[fcorluka]

I understand, but when you have 20+ custom fields on a module, and there are in specific order, and now I have to change all over and set labels (on panels) it is not so easy. Maybe merging goes simple and unpainful, maybe not.

[fcorluka]

I know that we went slightly off topic here, so I would like to give some feedback on this whole upgrade problem.

Putting upgrade files on CRM was no problem. Problems were appearing in the testing phase.
With debbuger, and log console I was able to solve it (this labeling problem).
Now I experience "Studio" problems where loading of items is taking too long (every time I click on Relationship part I have to wait 1-3 minutes).

I believe that all this is because of the great difference between versions (7.4.3. to 7.8.8), and my advice would be to make the upgrade as soon as possible on your CRM to avoid these situations.

Thanks @pgorod for all the help.

[Glen206]

It's been awhile, but I got this working for me by removing the php files in the
.../custom/modules/Cases/metadata

Did a quick repair and rebuild and i'm in business.

Thanks @pgorod, your post above about starting a fresh customization got me there.

We are currently on 7.9.8 but have continually updated since 6.5.20 and we've installed and removed plugins over the years, leaving some erroneous files that are not needed but interfere with usability at times.