Hi i ahve created a custom module and would like to add threaded comments - just like the one in cases, how would i go about doing this?
Thanks in advance
1 Like
I don’t know the answer, and I think it will be complicated, but you can start by looking at these files
modules/AOP_Case_Updates/AOP_Case_Updates.php
modules/AOP_Case_Updates/CaseUpdatesHook.php
I would love to know this too. I am not a coder, so in layman’s terms, please.
Sorry, in layman’s terms, non-coder terms, the answer is “it’s not possible”…
It’s not possible to answer in layman’s terms, or it’s not possible to add the case threaded updates to a custom module? Please specify.
Thank you.
Adding that feature is a complicated task for a coder. It’s not possible for a non-technical person.
Thank you.
I found myself thinking about this thread today, so I come back to add a comment. Fortunately, a non-technical comment.
When I started with SuiteCRM, my first approach was to do everything in “custom-mode”, start adding my modules, my fields, etc.
As years go by, I now favor the approach of trying to use as much of what is already there as possible, in the exact same way as it is there. The reason is that there are many hidden details, many simple improvements to fields (like email, threaded updates) that are hard or impossible to replicate in custom modules.
So you should consider if you can’t simply achieve your objectives with the Cases module.
I wrote this in my blog, regarding the Accounts and Contacts concepts, but it applies equaly to many other modules (like Cases):
I hope this helps. I think this kind of advice on SuiteCRM is missing from the Internet, that’s why I have a bunch of articles in my blog with the tag “Concepts”, to help with data modelling and process modelling around SuiteCRM.
1 Like
I agree with you. I am trying to use the modules as they are intended to their fullest, as there is no reason to reinvent the wheel where unnecessary. However, there are circumstances where customization of (even standard) modules is a priority.
This seems like a functionality that should exist without an engineering or computer science degree. Until that time, I will continue to tweak the system to “make it work” - not very efficient for a tool that is supposed to increase efficiency, but a girl’s gotta do what a girl’s gotta do!
There is an historical reason for the lack of integration of the threaded updates. This feature was not part of SugarCRM, it was a separate module that SalesAgility used to sell to it’s SugarCRM customers, before the fork. When they forked and created SuiteCRM, they basically offered all their modules to the Community, making SuiteCRM more full-featured. Some of these modules are quite powerful (like Workflows). But still, it shows that there is a “border”, a separating line, between these modules and the rest of the product.
A history lesson is always helpful in understanding outcomes. Thank you. I really do appreciate the feedback - it is helpful.
And thanks for letting me vent 
Sheri
I see this is an old thread but I wanted to share my experience.
I have managed to set this on one project a year ago (maybe two- suite version 7.8.12.).
Now I have to say on version 7.10.24. this does not work (text can not be saved), and I still have to figure out a way (I have one clue so far).
To get this work you need to do next:
- in custom module open metadata->detailviewdefs.php and copy in list (where you want it):
'LBL_AOP_CASE_UPDATES' =>
array (
0 =>
array (
0 =>
array (
'name' => 'aop_case_updates_threaded',
'studio' => 'visible',
'label' => 'LBL_AOP_CASE_UPDATES_THREADED',
),
),
),
- in custom/Extensions/MODULE_NAME/Ext/Vardefs create new file eg. vardefs.php, and copy inside
<?php
$dictionary['MODULE_NAME']['fields']['aop_case_updates_threaded'] = array(
'required' => false,
'name' => 'aop_case_updates_threaded',
'vname' => 'LBL_AOP_CASE_UPDATES_THREADED',
'type' => 'function',
'source' => 'non-db',
'massupdate' => 0,
'studio' => 'visible',
'importable' => 'false',
'duplicate_merge' => 'disabled',
'duplicate_merge_dom_value' => 0,
'audited' => false,
'reportable' => false,
'inline_edit' => 0,
'function' => array(
'name' => 'display_updates',
'returns' => 'html',
'include' => 'modules/AOP_Case_Updates/Case_Updates.php',
),
);
- create in custom/modules/MODULE_NAME a logic hook which will save text to correct parent
public function addUpdate(&$bean, $event, $arguments)
{
if(!empty($_REQUEST['update_text'])){
$cu = new AOP_Case_Updates();
$cu->name = $_REQUEST['update_text'];
$cu->description = $_REQUEST['update_text'];
$cu->internal = (int)$_REQUEST['internal'];
$cu->case_id = $bean->id;
$cu->assigned_user_id = $GLOBALS['current_user']->id;
$cu->save();
}
Problem with new version is in: modules/AOP_Case_Updates/Case_Updates.php
Line: 105/106 variable params
Old one (working):
var params =
"record="+record+"&module=" + module_sugar_grp1 + "&return_module=" + module_sugar_grp1 + "&action=Save&return_id="+record+"&return_action=DetailView&relate_to=" + module_sugar_grp1 + "&relate_id="+record+"&offset=1&update_text="
+ update_data + "&internal=" + internal;
New one (NOT working):
var params =
"record="+record+"&module=Cases&return_module=Cases&action=Save&return_id="+record+"&return_action=DetailView&relate_to=Cases&relate_id="+record+"&offset=1&update_text="
+ update_data + "&internal=" + internal;
As you can see now the module name is HARDCODED, don know why.
Best regards,
Filip
2 Likes
You can take the file modules/AOP_Case_Updates/Case_Updates.php into custom directory and change as per your requirements. In modules/Cases/vardefs.php you can see there are 3 fields that are pointing to this file and using its functions.
aop_case_updates_threaded
case_attachments_display
case_update_form
just create their custom definition and point to the custom file to make your updates work.
3 Likes
I believe my way works (I have test it using the old file in new crm), but your may be more correct; specially when it comes to upgrade.
I think if we could re-factor the code in Core a bit, we could make the threaded updates table keep a field to specify the module name of each entry. That way a single table could hold all threaded updates for all modules, and it would be quite easy to make this reusable across modules.
There are more things in that module that need refactoring, some best-practices that could be implemented, to make the code more versatile.
1 Like
By the way, I think this is coming in Suite8. The threaded updates can be used in any module.
1 Like
Hello this topic is a few years old, but did this feature manifest in Suite8? If so is there any documented references as to how to implement this?
hello, everyone!
It’s been a while since the first question, but the functionality can be achieved without having to use aop_cases_update
I did it as follows:
- with 2 fields per studio:
update_data_c and insert_data_c added in my custom module - an ajax in the detailed view js and a php that updates the update field and the insert_data_c is simply for the input where we write
- the ajax is executed every time an input is given or when a button is clicked
- the data is updated in the same table as the custom module
Matter resolved!
If there is interest I will share the code.