At that time I also mentioned how I had a couple of projects in mind related with the library I wrote then, curiously, one of these projects also matched a need felt by others: improving/automating the way how exchange rate updates are made in SugarCRM projects.

Two months later, more or less, I’m back with news regarding these projects: a few minutes ago I’ve released publicly, and more important, freely, my two first SugarCRM packages.

The first one, is Open Exchange Rates library for SugarCRM,  a package built to ease the pain of integrating the Open Exchange Rates library, in SugarCRM projects. The second one, actually depends on the first, is Currencies Exchange Rate Updater, a SugarCRM package designed to ease the process of updating active currencies exchange rates with the help of external data sources.

The video above, illustrates not only the installation process of these packages, but also the two different workflows supported by the latter, who enable an easy management of active currencies exchange rates updates. Either manually by filling latest rates values by hand or by importing these values from an external data source, or automatically, by defining a scheduler job who becomes responsible for performing this updates on a regular basis.

Both packages can be downloaded on SugarForge (here and here) and on GitHub (here and here) respectively.

Keep in mind that both packages are still beta, feel free to get in touch if you find some strange behavior, need any help or if you want to somehow contribute to any of these packages.

To finish, I would like to thank Joss Crowcroft for supporting the  Open Exchange Rates library developments by lending me a paid account in order to test paid services and Filipe Guerra for his feedback and help on testing both packages.

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.