Incidencia - Email - Error al auditar una propiedad del correo electrónico

[ManuSinergiaCRM]

Descripción del problema

Durante la implementación del PR #277 se detecta que al guardar un registro de persona se está auditando el valor del campo confirm_opt_in aunque este campo no se esté mostrando como opción del campo Correo Electrónico en el formulario de edición.

Desde Administración / Configuración de correo podemos configurar en el campo Configuraciones de Autorización dos opciones: Autorizar y Adhesion confirmada que hacen que se muestre la opción de Adherido (Opt_in) en el campo Correo Electrónico del formulario de edición de una persona.

Sin tener clara la operativa de estas opciones, se intuye que con la configuración de Adhesion confirmada, el CRM enviará un correo con la plantilla indicada en el campo Plantilla de e-mail de confirmación de autorización de la configuración general de correo. En el CRM existe una plantilla llamada Confirmed Opt In en cuyo contenido hay un enlace ($sugarurl/index.php?entryPoint=ConfirmOptIn&from=$emailaddress_confirm_opt_in_token) que aparenta ser quien gestiona la confirmación por parte del usuario, pero que al realizar pruebas no funciona ya que no resuelve la variable $sugarurl

Llegados a este punto, se pregunta al GPT de SuiteCRM como funciona es la operativa de la propiedad confirm_opt_in:

---

Paso 1: Configurar el campo "Email Opt-In"

En versiones recientes de SuiteCRM (7.10+), el campo principal utilizado para gestionar el consentimiento es email_opt_out en lugar de confirm_opt_in.
Este campo controla si un destinatario:
- Ha aceptado recibir correos electrónicos (Opt-In).
- Se ha dado de baja voluntariamente (Opt-Out).

En versiones anteriores, el campo confirm_opt_in complementaba este proceso, pero en versiones más nuevas puede estar deshabilitado o haber sido reemplazado por lógica más sencilla centrada en email_opt_out.

---

Tras la respuesta del GPT se amplia la duda a si se está usando esta operativa en SinergiaCRM... Se realiza una consulta a las diferentes instancias de entidad obteniendo los siguientes resultados:

• 2 entidades --> email_enable_confirm_opt_in = 'confirmed-opt-in'
• 15 entidades --> email_enable_confirm_opt_in = opt-in'
• El resto de entidades --> email_enable_confirm_opt_in = not-opt-in'

Visto esto, se proponen las siguientes alternativas de actuación:

1. Hablar con Jaume (una de esas dos instancias es la suya) o con AES para ver la operativa de trabajo con la opción de 'confirmed-opt-in' configurada.

2. Escribir a la comunidad de SuiteCRM para ver si alguien puede confirmar si dicha funcionalidad esta activa o algo relacionado

3. Proponer un PR a SA con alguna de las dos siguientes propuestas de actuación a nivel de código:

   a) En caso de que se determine no usar la funcionalidad de confirm_opt_in, una solución sencilla es anular la propiedad audited del campo confirm_opt_in en metadata/email_addressesMetaData.php

   b) Si por el contrario, es una funcionalidad que estará disponible para las entidades, la propuesta de solución sería añadir el siguiente código en la línea 3063 del fichero include/database/DBManager.php: $after_value = isset($bean->$field) ? $bean->$field : $before_value;

   Esta solución aparenta tener sentido ya que si un campo no existe en el bean que se está guardando es razonable pensar que la propiedad no ha sido modificada. Me preocupa que el cambio se realiza en DBManager.php y al ser un elemento raiz, quizá se pueda estar influyendo en alguna otra funcionalidad. A la par, da calma ver que la función modificada es llamada por otras (getAuditDataChanges() y auditBean()) cuyo ámbito es auditar y que solo son llamadas desde la funcionalidad de guardado o importación de un bean.