Add optional footer in emails

[juan-cortizas-ponte]

This code adds a new configuration parameter to configure an optional footer, for example, for a privacy policy notice

This option is configured with the $_configuration['notifications_extended_footer_message'] parameter and multiple paragraphs can be added:

$_configuration['notifications_extended_footer_message'] = ['paragraphs' => [
    'Change or delete this paragraph or add another one'
]];

Usage example:

$_configuration['notifications_extended_footer_message'] = ['paragraphs' => [
    'Nuestro horario de atención al público: de lunes a viernes, de 8 a 15 horas.',
    'Información sobre protección de datos: El responsable del tratamiento de los datos personales del destinatario es la entidad remitente de la presente comunicación. Dichos datos son tratados para la satisfacción de nuestro interés legítimo para la gestión de contactos y el mantenimiento de comunicaciones recíprocas por cuestiones derivadas de nuestra actividad. Estos datos serán conservados mientras sean útiles para la finalidad indicada, y, en todo caso, durante los plazos legales y para el tiempo necesario para atender a posibles responsabilidades nacidas del tratamiento. Los interesados tienen derecho a solicitar el acceso a sus datos personales, su rectificación, supresión o portabilidad, la limitación de su tratamiento, a oponerse al tratamiento, así como presentar una reclamación ante una autoridad de control.',
    'Este mensaje y sus documentos adjuntos son confidenciales. Si usted no es el destinatario, por favor póngalo en conocimiento del remitente y elimine esta comunicación y los documentos adjuntos de su sistema, sin reproducir ni comunicar sus contenidos. La transmisión de correo electrónico no garantiza que sea seguro o libre de error, por lo que declinamos cualquier responsabilidad al respecto'
]];

[juan-cortizas-ponte]

A litle update, added the funcionality to all emails sent by chamilo

[ywarnier]

@juan-cortizas-ponte Due to the fact there is not translation mechanism embedded in your solution, the configuration variable in configuration.dist.php should be language-specific. I don't really like the way it is right now (not flexible enough), but if you want it to be included, then it should look more like this

$_configuration['notifications_extended_footer_message'] = ['english' => ['paragraphs' => [
    'Change or delete this paragraph or add another one'
]]];

This way, several languages can be managed on a single portal. Obviously you also need to update your code to check for the current language (from api_mail_html(), for example). You can get the destination user's language by calling api_get_user_info($userId)['language']; and ensuring it's not empty (or replace it by the platform default language).

[juan-cortizas-ponte]

Thanks @ywarnier Im going to redo it based on your input

[ywarnier]

@juan-cortizas-ponte ping...

[juan-cortizas-ponte]

@juan-cortizas-ponte Due to the fact there is not translation mechanism embedded in your solution, the configuration variable in configuration.dist.php should be language-specific. I don't really like the way it is right now (not flexible enough), but if you want it to be included, then it should look more like this

$_configuration['notifications_extended_footer_message'] = ['english' => ['paragraphs' => [
    'Change or delete this paragraph or add another one'
]]];

This way, several languages can be managed on a single portal. Obviously you also need to update your code to check for the current language (from api_mail_html(), for example). You can get the destination user's language by calling api_get_user_info($userId)['language']; and ensuring it's not empty (or replace it by the platform default language).

@ywarnier I changed it based on your suggestions but I took a different aproach to the language matter.

To get the language I used api_get_interface_language(), why not get the recipient user language?, inside the same api_mail_html method there is this ThisIsAutomaticEmailNoReply language variable without a $language parameter, so it takes the global var $language_interface to get the value of the lang var and api_get_interface_language() get the language from this same global var.

Is this a correct aproach or the recipient user language must be checked?

[ywarnier]

Hi @juan-cortizas-ponte The changes you made last (merging with another branch) screwed your PR a little (somehow I get commits from the announcements branch as part of your PR).

Yes, you are right, we should probably use the recipient's language, but the api_get_interface_language() is supposed to take the user's language into account (plus context elements) to determine what language to use. But an issue is that it takes the current user's language into account rather than the recipient's language. By changing it to the recipient's language, however, you would be forcing it to the recipient's language as set in the user's profile, which is not always correct in the logic of Chamilo: by default, the language of the course has priority over the language of the user, for example, and this would not be reflected in e-mails sent from the course.

All in all, I agree that we should use the recipient's language (if defined, so check it and use api_get_interface_language() otherwise) by default, as we strive to make communications around a course as clear as possible, and using the recipient's language is better in that sense than focusing on using the context language (which will still be the case as soon as they click a link in the e-mail, for example).

[ywarnier]

I have accepted your PR to make things progress. Feel free to send another PR with the change to the recipient's language later on