One of the first customizations that I recall applying to the first SugarCRM system I was in charge of was to set the default assigned user on Cases to someone other than the logged in user. This was used as a way to simplify the need for the submitting user to have to select the same assigned user every time a new case was added. That was back in 2005, and using version 3.0 of the product.
Although the process is still not a simple matter of a couple of clicks of the mouse, major advancements to the SugarCRM architecture since that time have indeed simplified it when compared to when I first had to tackle the issue, so do not be discouraged.
Let us take a look at exactly how it is done.
The topic of Employees and Users within the scope of SugarCRM can sometimes be a bit confusing. However, there are a couple of subtle points that help distinguish the two.
In a nutshell, Employees are a representation of the various individuals that work at your organization. In some cases (maybe all), those same individuals are also SugarCRM users, but it is not mandatory. Users, on the other hand, are a representation of all the individuals that have access to the SugarCRM system. Note that anyone defined as a User is also automatically added to the Employees list -- which is often the reason why confusion creeps in when discussing this topic.
Another important difference between the two is that of the two, data can only be assigned to a User but not to an Employee. These subtle differences are specially important on commercial deployments (Professional, Enterprise Editions) as User counts are limited by the number of licenses one has purchased.
But what happens if one had a need to assign data to an Employee, for reference purposes?
Sometimes minor customizations to SugarCRM go a long way towards addressing important usability aspects. Something that has come up a couple of times in recent interactions with users is the need to truncate data displayed on a subpanel.
At first glance, the reasons why someone would want to do this are not always readily apparent. However, consider the scenario where one uses a text area field (e.g. description) on a module and one wishes to display that field on the subpanel.
The process of including the field on the subpanel is easily accomplished via Studio, but over time, an issue not initially apparent usually starts to surface.
Because a text area field can hold large amounts of text, it is possible for a user to populate the field with a number of pages worth of data. That on its own is not a problem. However, displaying that on a ListView, of which a subpanel is a good example, usually causes undesired display problems, as demonstrated by the image that follows (click to enlarge):
The issue at hand is that the Description field with the longer text value makes the subpanel appear a bit odd, to the point that the additional columns that are part of the view appear to the extreme right of the screen.
So how do we solve this? Easily, via a logic hook. Let us take a look at how we do so.
