SugarCRM: Label Placement

Sometimes things happen. Allow me to illustrate.

For a number of years, there has been a little known option within Sidecar view metadata that allowed one to define the placement of field labels relative to the data. You can see the setting defined in line 173 of the snippet pictured below:

Setting the value to false causes the labels to display to the left of the data, as illustrated in the image that follows:

Why would one consider using this feature?

The option has some limitations, but it is helpful for reducing the amount of white space visible to the user. This, in turn, makes the view more compact and allows for more data to be displayed within a given area of the screen. It is also applicable to all users, by default.

Additionally, it is also possible to set the label placement on a per panel or module basis, allowing more granular control over the placement of labels. An example of a per panel configuration is demonstrated below:

Regardless of the manner in which one wishes to implement this feature, it always requires manual intervention, given that the labelsOnTop attribute could not be set through Studio.

The manner in which label placement is defined changed with the release of Sugar 10. 

MySQL Troubleshooting: Error 1118 Row Size Too Large

A while back I found myself attempting to correct an issue relating to the restore of a MySQL database backup. The problem at hand was the result of a very large table that would halt the process with the following: 

Error 1118 Row Size Too Large.

The source of the error was a table that contained numerous fields, tallying in the hundreds. While the database contained this table with a large row size, it did not present any particular issues executing common operations such as INSERTs, UPDATEs or DELETEs. Problems were only present if one attempted to restore the database.

Following various attempts to correct the problem, the solution eventually revealed itself. As it turns out, in some versions of MySQL, a server parameter that enforces certain rules upon creating tables is enabled by default. This validation examines the row size of each table as it is being created and if it exceeds the row size limit for the server, an error 1118 occurs, causing the restore process to halt.

The server setting in question is:

innodb_strict_mode

The setting is either defined as on or off and only affects tables utilizing the InnoDB engine. 

Setting the parameter to off (innodb_strict_mode = 0) and restarting the server allows the restore process to complete. It is worth noting that turning off the setting merely changes the behavior of the server such that it reports row size violations as warnings instead of errors, but does not alter the ability of the server to support more fields per table. This latter point is important because attempts to add additional columns to a table with a large row size will also cause the referenced error.

More information on the setting is found at the following page:

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_strict_mode

 

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?