Subpanel Creep
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.
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.
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.
