Extrafields: extrafields are not available in the members emails

[Jacques83300]

Bug

When referencing to extrafields in the templates for members emails the field name (EXTRAFIELD_xxxxxx) is not replaced by its value and the field name is displayed.

Environment

• Version: 10.0.0
• Web server: Apache

Expected and actual behavior

The expected behavior is to have in members the extrafields replaced by their values when generating an email for the members. Currently these are not replaced in the templates and the email is sent by the extrafield name like in the template (EXTRAFIELD_xxxxxx).

Steps to reproduce the behavior

Create an email template like subscription request with extrafields, fill and validate the subscription formular.

[atm-maxime]

I had the same impression today on a contract card but then I remembered that the extrafields were created after the contract, so no data were stored in extrafields for this contract. In this case, the EXTRAFIELDS keys in the email are not present. Can you check ?

[Jacques83300]

In my case, EXTRAFIELDS are existing for the member. The issue occurs for example in a mail automatically sent after the member has autosubscribed. I hope this info will help but the issue is quite easy to reproduce.

[Jacques83300]

Hello, I just tested with the version 11.0.3 and, by checking the code, I have seen the EXTRAFIELD variable name has to be in uppercase. After changing my emails, it works better. The only problem concerns extra fields with no value (null value) which are not replaced as shown in the code (functions.lib.php line 6415):

// Make substitition for array $substitutionarray
foreach ($substitutionarray as $key => $value)
{
	if (!isset($value)) continue; // If value is null, it same than not having substitution key at all into array, we do not replace.

	if ($key == '__SIGNATURE__' && (!empty($conf->global->MAIN_MAIL_DO_NOT_USE_SIGN))) $value = ''; // Protection
	if ($key == '__USER_SIGNATURE__' && (!empty($conf->global->MAIN_MAIL_DO_NOT_USE_SIGN))) $value = ''; // Protection

	$text = str_replace("$key", "$value", $text); // We must keep the " to work when value is 123.5 for example
}

To have the same behavior as the other variables, I would suggest to change the line 6240 in functions.lib.php:

foreach ($extrafields->attributes[$object->table_element]['label'] as $key => $label) {
	$substitutionarray['__EXTRAFIELD_'.strtoupper($key).'__'] = $object->array_options['options_'.$key];
}

by

foreach ($extrafields->attributes[$object->table_element]['label'] as $key => $label) {
	$substitutionarray['__EXTRAFIELD_'.strtoupper($key).'__'] = (isset($object->array_options['options_'.$key]) ? $object->array_options['options_'.$key] : '');
}

This way, the null extra fields are replaced by an empty string like for the other parameters.

Thanks to let me know if you can integrate this small change in the code.

[dpriskorn]

Can you update to v12 and see if the problem persists?

[ksar-ksar]

Hello,

No answer to the last answer since a long time.

I will close the issue, but you can re-open is the problem persist.

[Jacques83300]

Hello,

Sorry for the delay. I have just tested with v13.0.2 and the issue is still there: if an optional extra field is empty, Dolibarr sets the extra field name in the email. See example below:

SECOND CONTACT : 
EMAIL : __EXTRAFIELD_EMAIL_SECONDAIRE__    INTITULE : __EXTRAFIELD_INTITULE_EMAIL_SECONDAIRE__

Can you please re-open this issue? Thanks.

[Jacques83300]

Hi,

I tested in V14.0.0 and the issue is still there: if an extrafield is empty, it is replaced by its ID and not by an empty string.

Thanks to fix it.

I don't know how to reopen a closed issue

[Jacques83300]

Hi, I don't want to close the issue as, after testing with version 15.0.3, the issue is still not fixed. Can you please keep it open? Thanks.

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).