SuiteCRM Cases module doesn't save the Updates - Text field in the edit view. When it is saved from the details view page, it works fine. Tried it with Bitnami vm of Suite CRM with no custom modifications, but still not working.
In the edit view page for a case, the Update-Text field should be saved when the case is saved.
The Update-Text field contents are not getting saved in the edit view. There's no error in the logs. I'm a newbie and don't really know how to debug the logs and am not sure about modifying any hooks, but since there's no modification , it should ideally be working.
@ppate67 I would advise that you contact Bitnami support on this issue. I have tested this in the most recent releases and it works as expected.
@willrennie I installed a fresh copy on my machine and it's still the same. When i update it from detail view, it saves the text, but when i do it from the edit view, it doesn't save anything and there's no error in the logs
@willrennie I can replicate on demo, although I'm not sure what the original intention of the "Updates - Text:" field is on the edit-view. Perhaps it's supposed to be hidden.
I have this same issue on 7.11.2; however, from what I can tell the demo site is not experiencing the same behavior.
@willrennie I think i found what's causing this but am not sure how to fix it. The case update hook being called is not getting the value of the update text field and that's why it's not going ahead with the save and returns back.
Please see the code below, if i comment out the check if (!$text && empty($_FILES['case_update_file']), a record is saved in the aop_case_updates table and i can see a new entry in the case updates threaded with no text.
public function saveUpdate($case)
{
$GLOBALS['log']->error('CaseUpdatesHook: saveUpdate Called...1');
if (!isAOPEnabled()) {
return;
}
global $current_user, $app_list_strings;
$GLOBALS['log']->error('CaseUpdatesHook: saveUpdate Called...2');
if (empty($case->fetched_row) || !$case->id) {
if (!$case->state) {
$case->state = $app_list_strings['case_state_default_key'];
}
if ($case->status === 'New') {
$case->status = $app_list_strings['case_status_default_key'];
}
//New case - assign
if (!$case->assigned_user_id) {
$userId = $this->getAssignToUser();
$case->assigned_user_id = $userId;
$case->notify_inworkflow = true;
}
return;
}
$GLOBALS['log']->error('CaseUpdatesHook: saveUpdate Called...3');
if ($_REQUEST['module'] === 'Import') {
return;
}
$GLOBALS['log']->error('CaseUpdatesHook: saveUpdate Called...4');
//Grab the update field and create a new update with it.
$text = $case->update_text;
$GLOBALS['log']->error($case->update_text);
**/*if (!$text && empty($_FILES['case_update_file'])) {
//No text or files, so nothing really to save.
return;
}*/**
$GLOBALS['log']->error('CaseUpdatesHook: saveUpdate Called...5');
$case->update_text = '';
$case_update = new AOP_Case_Updates();
$case_update->name = $text;
$case_update->internal = $case->internal;
$case->internal = false;
$case_update->assigned_user_id = $current_user->id;
if (strlen($text) > $this->slug_size) {
$case_update->name = substr($text, 0, $this->slug_size) . '...';
}
$case_update->description = nl2br($text);
$case_update->case_id = $case->id;
$GLOBALS['log']->error('CaseUpdatesHook: saveUpdate Called...5');
$case_update->save();
In my case I'm just completely missing the hooks from my custom/ directory; however, I'm not entirely sure how to "re-install" those hooks. I'm looking into it right now. Would love it if anyone had any pointers. Specifically getting AdvancedOpenPortal::installAOPHooks() to re-run without killing the current install.
I solved this by making a new installation and copying the hook needed hook files. It would be great if this was part of the Repair & Rebuild process.
I have also reproduced the problem on both a new installation, and on SuiteCRMs demo site (both v7.11.3) - but it wasn't a problem on an upgraded production system. I found a customisation in vardefs seems to be the key. If I add the following to a custom/Extension/modules/Cases/Ext/Vardef/customisations.php
...
$dictionary['Case']['fields']['description']['editor']='text';
...
the problem goes away. Given that the TinyMCE editor doesn't appear for Description on an edit view for an existing case (which I guess it should as it does on New case), that the system doesn't properly support multiple instances of TinyMCE on the same page, possibly causing conflicts on the update_text field
@domwatts Thanks for sharing. I don't have that file in my installation but i solved it in a similar manner.
I removed the line " 'editor' => 'html' for the updates-text field in the vardefs.php file under /modules/Cases/ and then did a quick repair and rebuild and it's working as expected.
@ppate67 Thanks for the feedback. I don't however think this issue should be closed though, as I think SalesAgility need to determine how best to deal with this. Plus the fix needs to be upgrade-safe.
@Dillon-Brown for my part, I prefer to use the edit-view update-text as it allows me to add formatting to the case update (which the detail-view update-text does not).
@domwatts I reopened it.
So, what is the suggested workaround?
Hi, Please share some workaround.