Skip navigation
All Places > Developer > Blog > 2014 > October
When it comes to CRM, sales professionals know where their customer relationships stand when they have clear insight into past events. The best CRM systems present a historical audit trail that is simple for end users to find – and even easier for them to understand. Here are two plugin tools that make it painless for Sugar users to get a quick glimpse into those critical history items.


Worklog Field


Jerry Clark has resurrected Jon Whitcraft’s first Worklog field as a Sugar 7-friendly plugin available for download from SugarForge. The Worklog field can be used in place of a standard Sugar textarea field to insert a widget where users can log comments and events. Each entry that is made via the widget will be displayed as a line item in an ordered list. Users can see who created each entry and when they posted it.


The Worklog field is Studio-enabled so the administrator of an instance with the package installed can create a “worklog” type field and place it on any Sidecar or BWC module’s record view without assistance from a developer.


The latest Worklog Field plugin can be downloaded from SugarForge or you can Fork it on Github to configure your own version.


Historical Summary



By Grabthar's hammer, you shall have a complete Historical Summary!


Out of the box, Sugar’s Sidecar modules feature a handy “Historical Summary” option that does an excellent job of aggregating activity records (emails, notes, calls, and meetings) and displaying them in a sortable and preview-able list view. But users still need to click on individual preview buttons for a glimpse into each line item.


The extended Historical Summary plugin, also developed by Jerry Clark, mimics the all-encompassing view of activities from the ”View History” option that was available in Sugar 6.x and earlier versions. The main benefit of the enhanced tool is the ability to scroll through a slide-down drawer that displays the contents of every email, note, call, and meeting that is related to the parent record. This saves the user time and clicks when they need to quickly scan a record’s history.


The Historical Summary plugin also makes it easier for users to search for key words and phrases to quickly jump to the history item they need. A simple Ctrl+F will leverage the browser’s ability to find the relevant activity record without the user having to click into each item’s preview.


The Historical Summary plugin can also be downloaded from SugarForge or you can Fork it on Github to configure your own version.

Post originally written by Jesse.


If you want to use namespaces following the PSR-0 standard for your custom code, it is now possible with the SugarAutoLoader in sugar7. Now you don't have to insert require statements all over the place.


SugarAutoLoader::addNamespace('Fbsg\\', 'custom/include/Fbsg');


Sugar's autoloader will now map requests for the class Fbsg\Example\Test to the file "custom/include/Fbsg/Example/Test.php".


Post From Faye Business Systems Group Director of Development Matthew Strickland


Contact Jesse Heller

Post originally written by Jesse.


When you work with something everyday, eliminating tedious and repetitive tasks not only improves your productivity but also helps your sanity. With Sugar, there are certain things we as developers are constantly doing; in some cases, over and over again. How many times have you run quick repair and rebuild?


Luckily, we program things. We write scripts that make our lives in that moment a tad bit easier. But it's easy to lose track of these things; we might even write the same tool over and over again.


In this series of posts, we're going to build a command line utility tool whose only purpose is to make life more beautiful. If you've ever used the laravel framework, you are familiar with the "artisan" tool which is built with the symfony console component. We are going to do the same thing.


The general idea here is to be able to call commands like these:


$ sugarcli admin:repair


$ sugarcli manifest:validate


Let's get started.


We are going to be using symfony console composer, so if you aren't familiar be sure to read-up on it. The first thing, we need to do is pull in our symfony console dependency in composer.json.



    "require": {


        "symfony/console": "v2.4.4"




    "autoload": {


        "psr-4": {


            "Fbsg\\": "src"







$ composer install


Notice that we are using psr-4 for are auto-loading our classes, as we will be using psr compliant namespaces.


Now that we have our dependencies installed to the vendor folder, we are ready to start.


In the next post, we'll be building the quick repair/rebuild command.


You can view the github repository here.


Post From Faye Business Systems Group Director of Development Matthew Strickland


Contact Jesse Heller