Safely Customizing a Core Bean in SugarCRM

When it comes to creating upgrade-safe and custom module-aware* solutions it can become quite the challenge when you need to add something to a core bean.

* Side Note: I have been looking for a way to define a customization that has little to no chance of conflicting with another installable module. Meaning that it doesn't use a custom view, controller, etc that another module may, by chance, also be using. Hence the term "custom module-aware" being used here. Feel free to share your own ideas for a self-explanatory term in the comments below.

In this example, we want to be able to allow users to grab cases that are either currently unassigned or perhaps have been created from a support portal and assigned to a global portal user. The way that users will be able to grab these cases is by clicking a link that is to be displayed on the ListView in place of the username.

To do this we need to extend the get_list_view_data function that the Case bean already defines. Since we want to avoid customizing a bean a new custom bean is created:

Since it is possible that someone else has also created a CustomCase class our class name is prefixed with our own "key". In this case "SO". It is still possible that SOCustomCase exists somewhere out there in the SugarCRM world, but it is even more unlikely than just CustomCase.

Within get_list_view_data the original get_list_view_data is called to ensure everything works as originally intended. Then, our custom logic is added to see if the assigned_user_id is empty or if it is set to our global portal user. If so, the assigned_user_name value gets changed to an image link. The link goes to a custom action that would then reassign the Case to the current user.

With the custom bean defined the next step is to tell the ListView to use it. This is where we lose the "custom module-aware" badge as we need to create a custom controller:

As you can see, it is very possible that any module may also need to add their own controller.php. However, the customization is still upgrade-safe as any SugarCRM upgrade will not overwrite this file.

In the above example, the bean gets re-instantiated, but this time using our custom class. Since this is done early enough in the chain the custom get_list_view_data function will be available at the time of output, which will eventually spit out the following desired link:

How to customize a bean and where to call it can be tricky and changes on a case-by-case basis. This post only captures one specific case. Have your own unique case you've done in the past?