SugarCRM: Related Data Interactions

Often times a customization we are working on requires us to interact with related data, usually records that are children of another. For example, a customization might require us to determine if a given Account record has 1 or more related Contacts. Or for that matter, we may need the collection of ID values that represent all the Calls linked to a Contact.

In either example, the path most often followed could be described with the following pseudo-code:

1. Instantiate the parent SugarBean object (e.g. Account/Contact record object)
2. Load the corresponding relationship to access the related data objects
3. Retrieve the related SugarBean objects representing the related objects

See below for a PHP snippet illustrating the above:



Line 12 in the above example would effectively create an array of SugarBean objects representing the linked Contacts. From that point forward, determining whether or not the Account has any linked Contacts becomes a simple matter of checking the size of the array. 

For the linked Calls example, the code would be very similar, except we would load the 'calls' relationship and the ID values we want would be in the SugarBean object array that results from executing the getBeans() method.

Now, all of the above would function just fine, but let us consider a few things about this approach.

SugarCRM: Customization Tips

One of the tasks we regularly perform within the Technical Account Management team at SugarCRM is review customizations, especially code level modifications. Two of the main objectives behind such reviews are: 

• Identify areas of opportunity (customizations that can be further refined or optimized)
• Catalog potential pitfalls one may encounter were the instance upgraded

A challenge posed by such reviews is that any given instance can include customizations that touch a wide variety of the framework features and in different ways. Despite this, certain patterns emerge that point at common habits that require some level of attention and are applied while customizing Sugar. The more common behaviors are discussed in this post in hopes they will help you avoid some frustrations.

1. Incomplete WHERE clauses. SugarQuery is the preferred mechanism for querying the Sugar database programmatically. However, executing an ad-hoc query is sometimes unavoidable. For such scenarios, always remember that Sugar performs soft deletes of its data. Thus, when attempting to interact with "active" records in the database, one must add the deleted = 0 condition to the WHERE clause, or run the risk of working with dirty data. This requirement spans across nearly all tables in the Sugar database, including the relationship tables such as accounts_contacts. Below is an example of its use:

SELECT * FROM contacts WHERE first_name = 'Angel' AND deleted = 0;

2. Using database platform specific features. Expanding on the previous point, the use of raw SQL queries is sometimes unavoidable. Should you find yourself in such a scenario, bear in mind the intended scope of your customization. If you intend for your customization to reach a large number of Sugar instances, avoid using database platform specific features as doing so will automatically cause your customization to only work on a single database platform. 

For example, should we rely on the database engine to generate a GUID for us, MySQL allows us to use the UUID(), whereas MS-SQL uses NEWID(). Herein is the value of generating such a value via PHP or JavaScript, instead of at the database level, given that leveraging the database engine to generate the value would effectively bind our customization to that database platform.

Elasticsearch: Heed the Warnings

A few posts on this blog have talked about different topologies one can use to deploy Sugar, either for development purposes or production use. Perhaps the most important point in those posts is the matter of ensuring that one should not expose the Elasticsearch server to any other machine besides the one where the web server is running.

Because Elasticsearch data can be read without any sort of user authentication, exposing an Elasticsearch server means one is allowing potentially malicious users to view sensitive data. Despite this risk, it is not uncommon to hear of Sugar implementations that are configured in ways where Elasticsearch can be directly accessed via the internet or local network. 

A few days ago, the dangers of such a configuration were further highlighted by ransomware makers. Reports have recently surfaced that data from exposed Elasticsearch servers is indeed being compromised and held hostage.

This threat may leave some Sugar administrators wondering about the impact this could have on their Sugar implementations and data.