A Tale of Two Maxes

A few days ago an odd error message experienced by a SugarCRM user made its way to my desk. After scratching my head for a few minutes, some ideas for its source came to mind and the problem was corrected. 

Soon thereafter, a similar scenario once again made its way to me, but the conditions causing the error seemed a bit different. Fortunately, both scenarios resulted in similar errors and the solution for the prior scenario was equally applicable to the latter.

This is the error, extracted from the sugarcrm.log file:

MySQL error 1439: Display width out of range for column '<some_field_name>' (max = 255)

So what is this error telling us? The error is telling us that the referenced field cannot be created because its definition indicates a desired width larger than 255. In this particular case, it was an integer field, which in turn translates to a field that can hold more than 255 digits. Note that this a reference to the number of individual digits the field can hold, or its width, not the maximum value it can hold. This brings us to the crux of the problem.

SugarCRM 101: Leads, Contacts, Accounts and Opportunities.

Have you ever wondered about the reasons why some modules exist within SugarCRM? The reason is not always obvious, especially to someone new to the sales/marketing world, and often prompts questions.

Perhaps no other area generates more questions than the Leads, Contacts, Accounts and Opportunities modules. To some, the data contained in some of those modules seems redundant, especially the first two as they both contain data about individuals. In other cases, their usage seems like overkill. Yet others are confused as to their need, due to semantics, for example, to some a Lead and a Contact are synonymous with each other. 

Lets try to unravel some of this confusion and answer some of these questions.

If we quickly analyze sales procedures at a variety of businesses, we discover some commonalities across many industries, regardless of the size of the business. Here is a summary:

1. Someone, typically in marketing, is in charge of attracting potential buyers of your services/products. 
2. A potential buyer responds and is screened/qualified, to determine their specific interest and purchasing power. 
3. Lastly, a deal is worked and if won, the potential buyer becomes a paying customer.

That is a very simplistic look at a sales cycle, but it serves our purposes rather well. 

Modern CRM systems, such as SugarCRM, are designed with the above principles in mind. As a result, they include functionality aimed at helping users more clearly differentiate the type of customer information they are looking at to fit in within those various points listed above. More specifically, an application like SugarCRM clearly draws a line between a potential customer and a paying customer, as well as what deals are in the works. 

That, in short, is the reason why the various modules exist, but lets talk some more about their usage.

SugarCRM Customization: User Specific Dropdown Lists

Here is a scenario that has come up a couple of times in the last few weeks: 

While working with Opportunities, we wish to limit the choices available within the Sales Stage dropdown list, but based on the user that is currently accessing the record.

If you are wondering as to the reasons for such a request, consider a scenario where you wish to ensure that opportunities are not accidentally (or not so accidentally) moved to another sales stage by folks that do not have the authority to do so. Eliminating choices from the dropdown list would be the easiest way to ensure certain values are not selected. 

For the purposes of our example we will assume that we wish to eliminate Value Proposition as a choice from the Sales Stage dropdown list, but only for the user chris.

To do this, we first need a copy of the language file containing the dropdown list values. Using your text editor of choice, open the file en_us.lang.php, found in the /custom/include/language folder. If the file is not there, access Admin > Dropdown Editor, then select sales_stage_dom and click Save.

Once the file is open, you should see something similar to the following:

<?php
$GLOBALS['app_list_strings']['sales_stage_dom']=array (
  'Prospecting' => 'Prospecting',
  'Qualification' => 'Qualification',
  'Needs Analysis' => 'Needs Analysis',
  'Value Proposition' => 'Value Proposition',
  'Id. Decision Makers' => 'Id. Decision Makers',
  'Perception Analysis' => 'Perception Analysis',
  'Proposal/Price Quote' => 'Proposal/Price Quote',
  'Negotiation/Review' => 'Negotiation/Review',
  'Closed Won' => 'Closed Won',
  'Closed Lost' => 'Closed Lost',
); 

The bit of code above is the definition of the values displayed in the Sales Stage dropdown list. Next, we need to add our code that determines the current user and if it happens to be chris, instruct Sugar to remove the Value Proposition choice.

This is the code we will use, immediately following the code that defines the list:

//Retrieve user object for currently logged in user

global $current_user;

//Check if currently logged in user is indeed "chris"
if ($current_user->user_name == 'chris')
{
       //Remove choice for Value Proposition
unset($GLOBALS['app_list_strings']['sales_stage_dom']['Value Proposition']);
}

Save the file and you are ready to go! 

Update: Cédric Mourizard (@cedricmourizard), SugarCRM Engineer at Synolia (@synolia), was kind enough to share an observation about this topic via Twitter. In short, take care when limiting choices, as it could cause inadvertent data loss. For example, if a user that does not have access to the Value Proposition option edits an Opportunity whose sales stage is set to Value Proposition, saving that record would force the user to choose another value for the Sales Stage. This may or may not present a problem for your needs, but it is something to bear in mind. 

SugarCRM 101: Multiple Businesses Continued

Recently I found myself reviewing a behavioral issue in SugarCRM that coincidentally had affected another user a few months prior.

While reviewing the matter, it became evident it fit in nicely with the list of reasons it is generally not a good idea to use a single install of SugarCRM for multiple businesses, commonly referred to as a multi-tenant implementation.

This time around, the issue revolved around email and the manner in which messages link themselves to records in SugarCRM. In general, SugarCRM utilizes the email addresses associated with a record to determine which records should be linked to the message. Thus, the FROM, TO, CC and BCC addresses on a message are all relevant because if the address is associated with a record in SugarCRM -- be it an account, contact, or other -- the email message will automatically associate itself with that record. Said message would, for example, appear on the History subpanel of the contact with the matching TO address, as well as that of the contact with the matching CC address. Herein lies the potential problem. 

Within an implementation intended to conform with multi-tenancy standards, the record with the TO address may not be accessible to a user that does have access to the record with the CC address. Perhaps the records represent individuals in different territories or serviced by different business units, etc. Whatever the reason, it is possible that a given user of the system does not have access to both records that correspond with the two email addresses. 

Regardless, the email message is linked to both records and History information could be exposed to unintended users. Take note that security issues of this type often times cannot be addressed as they are a direct result of the architecture of SugarCRM. 

Thus, once again, one should heed the warning that problems may arise (sometimes not readily apparent), if one chooses to use the system in a multi-tenant manner. 

SugarCRM: SOAP API Performance

It is not uncommon for discussions that revolve around the SOAP API in SugarCRM to include some measure of criticism, but how much of that criticism is actually warranted?

SOAP --the protocol-- has always been critiqued for not being an optimal method for communication between distributed systems, in short, poor performance. Thus, it is no surprise that some of that criticism should find its way into conversations about the SugarCRM SOAP API.

Some folks in the broader web development world have altogether given up on SOAP, favoring RESTful web services. True to the trends in the general web development community, many SugarCRM developers have also tossed aside any notions of using the SOAP API, and SugarCRM addresses this trend by also providing a REST API. However, this growing resentment towards all things SOAP makes me question whether it is justified, and if so, what can be done about it?

Before we go any further I should state I do not discount the point that test results can prove REST to be faster than SOAP, but I do think many performance problems attributed to the SugarCRM SOAP API can be overcome with some fine tuning of code. 

In my experience, the most common source of performance problems has come from the use of the set_relationship() method. Said method is used to create a relationship between records, for example, link an opportunity to a contact. All efforts should be made to reduce the number of times this method is called within your code.