Reintroduce process_record Hooks for ListView in SuiteCRM 8

[cvillarongace]

Feature

Feature Request: Reintroduce process_record Hooks for ListView in SuiteCRM 8

Summary

In SuiteCRM 7, the process_record logic hook allowed developers to dynamically process each record displayed in the ListView. This feature was particularly useful for adding or modifying data dynamically at runtime for fields that are either non-db or calculated. However, in SuiteCRM 8, the process_record hook does not work in the ListView, specifically for modules such as AOS_Quotes.

Context

The process_record hook in SuiteCRM 7 provided a critical capability for developers to:

1. Add dynamic values to individual records based on business logic.
2. Perform calculations or transformations on fields displayed in the ListView.
3. Extend and customize the ListView functionality for specific use cases.

This hook was commonly used in scenarios such as:

• Displaying non-database fields dynamically.
• Generating calculated fields.
• Contextual information is added to each record in the ListView.

Issue in SuiteCRM 8

In SuiteCRM 8:

• The ListView logic has been rewritten to leverage GraphQL and Symfony.
• The process_record hook is not invoked when retrieving records for the ListView.
• As a result, developers can no longer dynamically process records for the ListView using the familiar process_record logic.

Example Use Case

In AOS_Quotes, a developer may need to dynamically populate a field such as your_non_db_field in the ListView. In SuiteCRM 7, the following process_record logic hook would achieve this:

$hook_array['process_record'][] = array(
    1,
    'Add Non-DB Field Value',
    'custom/modules/AOS_Quotes/CustomLogicHook.php',
    'CustomLogicHook',
    'addNonDbFieldValue'
);

With the hook implementation:

class CustomLogicHook
{
    public function addNonDbFieldValue(&$bean, $event, $arguments)
    {
        $bean->your_non_db_field = $bean->field1 . ' - ' . $bean->field2;
    }
}

This no longer works in SuiteCRM 8 due to the architectural changes.

Impact

1. Lost Customization Capability:

   • Developers now face significant limitations when implementing dynamic fields or calculated data in the ListView.
   • Common use cases for non-db fields and business-specific logic cannot be implemented as easily as before.

2. Increased Development Complexity:

   • Workarounds such as extending Symfony services or modifying GraphQL resolvers require more effort and expertise, which can deter developers from customizing SuiteCRM.

3. Regression from SuiteCRM 7:

   • This feature was widely used and considered a staple of SuiteCRM 7 customizations. Its absence in SuiteCRM 8 represents a regression in functionality.

Proposed Solution

To address this issue, the following enhancements could be made to SuiteCRM 8:

1. Reintroduce support for process_record hooks in the ListView by integrating a hook system into the GraphQL resolver for ListView data.
2. Provide a dedicated mechanism for dynamically processing records before they are displayed in the ListView.
3. Allow developers to define dynamic logic for both database and non-db fields in a way compatible with the new architecture.

Benefits of Reintroducing the Feature

1. Improved Developer Experience:
   • Restores a familiar and efficient way for developers to add dynamic business logic to the ListView.
2. Backward Compatibility:
   • Supports legacy customizations and eases the transition for developers upgrading from SuiteCRM 7 to SuiteCRM 8.
3. Enhanced Customization:
   • Empowers developers to create more robust and tailored solutions for their business needs.

Request to the SuiteCRM Community

We request the SuiteCRM team to consider reintroducing this feature or providing an alternative mechanism to achieve the same functionality in SuiteCRM 8. Maintaining parity with SuiteCRM 7's customization capabilities will ensure a smoother upgrade path and better adoption of SuiteCRM 8 by the community.

[pgorod]

I don't think this is the way to go, although I recognize your description of the current limitations is accurate - we're currently not in a good place.

In the near future, additional field Logic options will be available, and especially the low-code-style features of PowerFields which are like calculated fields on steroids (big steroids). There are also changes coming in to facilitate making extensions (boilerplate code) so that people who are less proficient in modern PHP can still know where to put "their line of code" and get immediate effects.

Anyway, a case could theoretically be made for re-adding process_record hooks simply for backward compatibility, so that existing customizations "just work", even if the scheme is marked as deprecated and would eventually be removed. But I am almost certain that this would face insurmountable technical issues. Those hooks can simply change a field value, which is easy to handle in the new UI, but they can also do an infinite number of other things, including many that make assumptions about the HTML structure and have dependencies on legacy views... so that could never work.