When it comes to labels, by default, this function only loads current module labels into SUGAR.language.

These labels are acessible through the following command:

SUGAR.language.get('<ModuleName>', 'LBL_<LabelName>');

In order to add support to other module labels to be included, you should override _displayJavascript() method in your modules view, and specify which other modules labels should be included.

// modules/<ModuleName>/views/view.edit.php

require_once 'include/MVC/View/views/view.edit.php';

class <ModuleName>ViewEdit extends ViewEdit
{
    protected function _displayJavascript()
    {
        parent::_displayJavascript();

        if (!$this->_getOption('show_javascript')) {
            return;
        }

        $modules = array(
            '<Module1Name>',
            '<Module2Name>',
        );

        foreach ($modules as $module) {
            if (!is_file($GLOBALS['sugar_config']['cache_dir'] . 'jsLanguage/' . $module . '/' . $GLOBALS['current_language'] . '.js')) {
                require_once 'include/language/jsLanguage.php';
                jsLanguage::createModuleStringsCache($module, $GLOBALS['current_language']);
            }
            echo '<script type="text/javascript" src="' . $GLOBALS['sugar_config']['cache_dir'] . 'jsLanguage/' . $module . '/' . $GLOBALS['current_language'] . '.js?s=' . $GLOBALS['js_version_key'] . '&c=' . $GLOBALS['sugar_config']['js_custom_version'] . '&j=' . $GLOBALS['sugar_config']['js_lang_version'] . '"></script>';
        }
    }
}

Like all other stuff made in SugarCRM, this process also depends on what type of module you’re hacking, in other words, the place where you’re going to write the logic depends if you’re hacking a custom module or a core one.

Before you perform view customizations on core modules you should check first if the view is already implemented, in this case, you should check if the following file exists:

modules/<ModuleName>/views/view.edit.php

If so, you should create a new file on:

custom/modules/<ModuleName>/views/view.edit.php

and add further customizations.

Beware that on latest SugarCRM versions, you’re able to create custom views without having to copy all the logic from the core ones, and by that I mean that now you’re able to “truly” extend the custom views from the latter.

In order to achieve this the view name should be prefixed with ‘Custom’:

// custom/modules/<ModuleName>/views/view.edit.php

require_once 'modules/<ModuleName>/views/view.edit.php

class Custom<ModuleName>ViewEdit extends <ModuleName>ViewEdit {
    /** 
     * ...
     */
}

If by instance you’re hacking a core module that doesn’t have the view defined, you should create it like the example above but with a few differences:

// custom/modules/<ModuleName>/views/view.edit.php

require_once 'include/MVC/View/views/view.edit.php';

class Custom<ModuleName>ViewEdit extends ViewEdit {
    /** 
     * ...
     */
}

One thing to keep in mind is that if you’re hacking a custom module, you are able to choose which directory suits you best. As opposite to the examples above, on the example below, the logic is written directly on the module main folder.

// modules/<ModuleName>/views/view.edit.php

require_once 'include/MVC/View/views/view.edit.php';

class <ModuleName>ViewEdit extends ViewEdit
{
    public function display()
    {
        $this->_processDuplicate();
        parent::display();
    }

    /**
     * How bean will act on edit view when it's being duplicated.
     */
    protected function _processDuplicate()
    {
        if ($this->ev->isDuplicate) {
            $this->bean-><FieldName> = '';
        }
    }
}

Thanks to Jeff Bickart of Nepo Systems and Matthew Poer of Profiling Solutions for pointing the “truly” Custom views feature out.