When we create a custom module in SugarCRM (eg «grt_Providers_Contracts») and create a link or relationship between that module and one that uses the «Related to» field type such as «Tasks», we probably will want to search all the tasks related to our new module «grt_Providers_Contracts» from the simple or advanced search form from «Tasks» module.

However, there is a bug in SugarCRM that prevents us to retrieve tasks related to a custom module if that module has underscores (_) within his name, showing the following fatal error:

mod_fcgid: stderr: PHP Fatal error: require_once(): Failed opening required '' (include_path='/var/www/vhosts/daniloaz.com/subdomains/sugarcrm64/include/..:.:') in /var/www/vhosts/daniloaz.com/subdomains/sugarcrm64/data/SugarBean.php on line 3185, referer: https://sugarcrm64.daniloaz.com/index.php?module=Tasks&action=index

Cause of the problem

This is because when building the WHERE clause of the SQL statement that SugarCRM generates from the search form, SugarCRM obtains the two interconnected entities or modules from a faulty regular expression when we are dealing with «Related to» field types. That faulty regex appears few lines before line 3185 of file data/SugarBean.php and does not consider underscores that may appear in the name of such related entities:

$match = preg_match('/(^|[\s(])parent_(\w+)_(\w+)\.name/', $where, $matches);

Thus, in the specific case of our module «grt_Providers_Contracts», we may never get satisfactory search results because the name of the module that SugarCRM takes from the regular expression is «grt_Providers_Contracts_grt» instead of «grt_Providers_Contracts». This causes failure when the line 3185 from the date/SugarBean.php («require_once($beanFiles[$beanList [$joinModule]])» script is executed. A fatal error is then displayed because the $joinModule variable does have a wrong value, «grt_Contratos_Proveedores_grt», a module name wich doesn’t exist in the global module list handled by the SugarCRM instance, which is collected by the $beanList array.

As a disclaimer, the «grt_» prefix is a key I always add to the name of every new custom module, indicating the customer for which I am developing that module, so that it is unique and can not cause interference with other third-party custom modules.

Solution

The fix to this flaw is simple once you know what causes the problem, and consists in modifying the erroneous regular expression like this:

if (!strstr($where, 'grt_'))
    $match = preg_match('/(^|[\s(])parent_(\w+)_(\w+)\.name/', $where, $matches);
else
    $match = preg_match('/(^|[\s(])parent_(grt_\w+)_(grt_\w+)\.name/', $where, $matches);

Once this is done the problem is solved and we can perform searches of tasks related to our new module with no problems.