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.