SugarCRM Customization: CSS and Label Tricks

A few weeks ago, a colleague and I were posed an interesting customization scenario pertaining to an easily overlooked area of Sugar. Before we dive into the details of the scenario and corresponding solution, let us review some of the background.

Have you ever wondered where the abbreviations and icon colors for the various modules within your Sugar instance are defined? 

Here are a couple of examples of their use:

The abbreviations and accompanying icon color are automatically defined for each default module that is part of Sugar. Taking a closer look at the abbreviations, you will notice that there is pattern to the value, as it uses the first two letters of the corresponding module name. However, there are also exceptions, where specific letters are used to define the abbreviation, usually to avoid conflicts or more clearly define the abbreviation. 

Custom modules that are added to a given instance follow the same conventions and abbreviations and icon colors are automatically assigned to them too. But how are exceptions handled for custom modules? Or for that matter, perhaps we wish to change one of the default abbreviations or icon colors. How would we go about applying such a change?

SugarCRM Customization: Sending Emails - New and Improved

It seems like an eternity since I posted examples on programmatically sending emails through Sugar.

As some of you might have already correctly surmised, a number of changes have occurred to Sugar since those blog entries were written. One of the major additions to Sugar since then has been SugarBPM, which itself includes an email template engine.

Let us revisit the original problem of programmatically sending emails and examine how we can accomplish the same via SugarBPM. This time around, we will assume our intention is to send an email about an Account record.

We will first need to create the email template containing the content to be sent. Said template can be static or, if desired, may also include references to specific fields from the target module, to be parsed at send time. For our example, we may wish to make an email template that reads as follows:

ACME Corporation
123 Main Street
Some City, CA 90000

...but rather than typing specific values, we would instead insert references to the corresponding fields that contain the values we want from the Accounts module -- our Target Module. That would make the template much more flexible.

Note that the process of creating such a template for SugarBPM differs than that for a standard email template. To create an email template for SugarBPM, select Process Email Templates from the Sugar navigation bar and then click Create. Further information pertaining to this process can be found here:

https://support.sugarcrm.com/Documentation/Sugar_Versions/9.0/Ent/Administration_Guide/SugarBPM/Process_Email_Templates/index.html

SugarCRM: Exceptions

A number of years ago I read a funny comment about computers which read as follows:

"The problem with computers is that they do what you tell them to do, not what you want them to do."

The point being that computers do not think, they just follow instructions. As such, programmers have to be mindful of the instructions given and anticipate problems. While it is not possible to account for every possible scenario that may generate a problem, we do want to accommodate common scenarios and capture problems as exceptions, allowing our code to fail gracefully and providing feedback to the user in the form of an error message.

Within the Sugar framework, it is possible to easily implement such exceptions and provide feedback to the user.

An exception class, named SugarApiException, is provided out-of-box and can be implemented into your PHP customizations as illustrated by the following pseudo-code:



For the above example, the Sugar API would return a response code of 422, with the body of the error message being the string defined in the code (i.e. 'You are missing a parameter required for properly invoking this endpoint.').

Of course, this would be more useful if we had a selection of response codes and errors. The list of available options is defined within the previously mentioned SugarApiException class, found in the following file:

./include/api/SugarApiException.php

Here is the definition for the example used in the pseudo-code, where you will see the response code and error title:

/**
 * One of the required parameters for the request is missing.
 */
class SugarApiExceptionMissingParameter extends SugarApiException
{
    public $httpCode = 422;
    public $errorLabel = 'missing_parameter';
    public $messageLabel = 'EXCEPTION_MISSING_PARAMTER';
}

Hopefully this will help save you time implementing a process for handling errors!