Fix #10355 - Template Parser for extended modules

[ojs87]

Description

Modules that are extended in the custom folder, e.g. AOS_Quotes.php, are not correctly replacing variables based on the variables available in the Email Templates module. This is due to an extended module using a different beanList name(e.g. customAOS_Quotes) and the template parser using that beanList name as the key for the variables.

Motivation and Context

Extended modules should use the same basic variables in the Email Template editor to parse Email Templates

How To Test This

1. Extend the AOS_Quotes.php file by adding it to the custom/modules/AOS_Quotes folder and creating a basic class

<?php
if (!defined('sugarEntry') || !sugarEntry) {
    die('Not A Valid Entry Point');
}
require_once('modules/AOS_Quotes/AOS_Quotes_sugar.php');

class CustomAOS_Quotes extends AOS_Quotes_sugar
{
    public function save($check_notify = false)
    {
    
        $saved = parent::save($check_notify);

          return $saved;
       }
}

2. Add the required global name changes for the module in custom/Extension/application/Ext/Include/AOS_Quotes.php file

<?php
$objectList['AOS_Quotes'] = 'AOS_Quotes';
$beanList['AOS_Quotes'] = 'CustomAOS_Quotes';
$beanFiles['CustomAOS_Quotes'] = 'custom/modules/AOS_Quotes/CustomAOS_Quotes.php';

3. Repair and rebuild and create an email template for quotes, then a workflow to send an email when a quote is created
4. Create a quote
5. The sent email will not parse the variables correctly

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Final checklist

• My code follows the code style of this project found here.
• My change requires a change to the documentation.
• I have read the How to Contribute guidelines.

[serhiisamko091184]

Hey @ojs87,

thanks a lot for contributing to the project!

Regards,
Serhii

[johnM2401]

Hey @ojs87 !

I've given this a test locally and this does appear to resolve the issue when sending via the Workflow-Send Email action.

However, I see that the issue is still present when sending an Email via the regular Email->Compose action.

For example
Using the same Email Template and Quote selections on Email->Compose

Before Extending Quotes:

After Extending Quotes:

If possible, could you investigate and resolve this aspect too?
(If you feel this would need a longer investigation/fix, I would be happy to raise this as a separate Github issue so we can close and merge this fix. Please let me know if so)

Thanks!

[ojs87]

Hey @ojs87 !

I've given this a test locally and this does appear to resolve the issue when sending via the Workflow-Send Email action.

However, I see that the issue is still present when sending an Email via the regular Email->Compose action.

For example Using the same Email Template and Quote selections on Email->Compose

Before Extending Quotes:

After Extending Quotes:

If possible, could you investigate and resolve this aspect too? (If you feel this would need a longer investigation/fix, I would be happy to raise this as a separate Github issue so we can close and merge this fix. Please let me know if so)

Thanks!

Hi @johnM2401,

Thanks for testing that, I think this needs to be put on hold for now. This won't work for a Cases email template since the beanList value for cases is aCase and the table_name is case, so a little bit more thought is needed here.

Template parsing may need looked at so that the Compose view uses the same parser as the Workflow send Email action.

This is not ready to merge as it stands!

Thanks,
Owen