W-Systems joins SugarCRM! Read Blog

Addressing Subpanel Creep in Sugar 7.7

by Sarah Friedlander Garcia on March 3, 2016

7 minute read

The Subpanels section is where you find related records for the current displayed Sugar record. This is a vital feature because it allows a user to get a unified view of all the CRM records related to a particular record.  Who are the Contacts associated with the Account? When is the last time I talked to this Customer?  These answers are typically found within the subpanel section.

A very common customization in Sugar is to create new Custom Modules or to add new types of relationships between existing modules in the CRM. For example, at SugarCRM we use Sugar to track Sugar Subscriptions within a custom module. These Sugar Subscriptions are related back to the Account record for each and every customer we have. So there is a Subscriptions subpanel that appears on every Account record for this relationship.

Module relationships and even custom subpanels are slowly added over time to every Sugar instance – but rarely does anybody go back and remove them. This can cause problems since every subpanel has a cost associated with it.

Each subpanel is populated via an API request that queries additional database tables. Also, each subpanel adds weight to the client user interface with additional HTML and JavaScript objects associated with them. If you have 15, 20, or more subpanels on your modules then opening a single record can generate a lot of overhead as these panels are rendered and are populated.

Performance is a priority at SugarCRM Engineering. So it was necessary for us to tackle this common issue head on.

If you are in the Sugar Beta program, then you can try out the Sugar 7.7 Beta to observe the following changes.

Sugar Developers who have heavily customized Sidecar Subpanels need to carefully test their customizations when upgrading to Sugar 7.7.

Refactored to Improve Subpanel Performance

We have (re)introduced record counts on subpanels.

Subpanels with counts in Sugar 7.7

This is a great UX touch! It also helps avoid situations where users open subpanels just to see if there are new related records.

We have also optimized the rendering of Subpanels so that subpanel lists are rendered only when subpanel is expanded. Previously, they would be rendered as hidden HTML which would impact client side performance unnecessarily.

A full related record query that selects all fields in list view is only used when the subpanel has been expanded.

These changes necessitated a refactor of functions related to toggling and rendering of subpanels. Sugar Developers who have heavily customized Sidecar Subpanels need to carefully test their customizations with Sugar 7.7.

System Setting to Collapse Subpanels by Default

In the past, Sugar would always fetch subpanel data immediately upon navigating to a record view. Subpanels that were opened by users would be “sticky” and remain open when users visited other records within the same module.

For example, if you left the Contacts subpanel open on the Accounts module, then every time you returned to an Account the Contacts subpanel would be open and related record data would be fetched to populate that subpanel.

This behavior can now be controlled using a System Setting.

New collapse_subpanels in Sugar 7.7

With the collapse_subpanels configuration setting enabled, all Sidecar subpanels will be collapsed by default for all users when they visit Record views.

Enabling the $sugar_config[‘collapse_subpanels’] setting is highly recommended for Enterprise customers or situations where “subpanel creep” has taken hold in your Sugar deployment.

This article originally appeared on the Sugar Developer Blog and was authored by Matthew Marum.