Hotfix - Campañas - Auditar los cambios al pulsar en el enlace de baja de una campaña de email #277
Conversation
|
Actions executed at: 2024-12-24 13:15:14. |
AlbertoSTIC
requested review from
enricsinergia and
jordiSTIC
and removed request for
AlbertoSTIC
|
Se observa que al marcar el opt-out desde la interfaz de Persona, sólo se guarda en la tabla audit la primera de las direcciones sobre la que se aplica el cambio. Quizás habría que incluir también esta corrección para que tenga realmente sentido grabar en el log cuando viene del removeme.php |
|
Se verifica que al pulsar el enlace para darse de baja, se registra la baja de todos los correos de la persona o interesado, auditando los cambios para cada una de las direcciones Se observa que desde la edición de los datos de una persona, al cambiar el valor de "Refusado" de un correo, únicamente se audita para la dirección principal de la persona:
Observación: Parece ser que las campañas únicamente envían correos a la dirección principal de un contacto, y únicamente si esta no está marcada como "Refusado" ni "No válida" |
modules/Campaigns/RemoveMe.php
Outdated
| (id, parent_id, date_created, created_by, field_name, data_type, before_value_string, after_value_string, before_value_text, after_value_text) VALUES | ||
| ('$newId', '$emailAddressId', UTC_TIMESTAMP(), '1', 'opt_out','bool','0','1',NULL,NULL)"; | ||
| $result2 = $db->query($query); | ||
| if ($result2) { |
There was a problem hiding this comment.
La condición de error está invertida: si falla $result2 devolverá false
There was a problem hiding this comment.
Cambiado 👍
There was a problem hiding this comment.
- La verificación de la segunda query está invertida. (ver comentario)
- Se podría añadir también control de errores en la primera query
- En el caso que
$emailAddressesIDesté vacío se generará query incorrecta (se da de baja persona a la que se le han eliminado los correos en el crm)
Hecho |
|
Tras comentarlo con Alberto y por coherencia, se ha decidido auditar todos los emails rehusados ya sea en el proceso de baja de una campaña de tipo Email como desde la UI, donde se ha detectado que solo se audita el rehusado del email principal. |
En relación a la observación, el email principal de la persona se almacena en un campo llamado email1 que por defecto no tiene activada la propiedad de auditado, pero si se activa sí se audita el campo |
There was a problem hiding this comment.
En la acción de rehusar desde la interficie del CRM se graba también un cambio en la propiedad del confirm_opt_in cuando no se realiza cambio. Este registro se graba tanto al rehusar como al desmarcar el flag de rehusado.
A pesar de no ser una incidencia producida por este PR, creo que valdría la pena solucionar este tema ya que estamos arreglando los audits del rehusar.
|
He estado mirando cual es la operativa de confirm_opt_in y no acabo de saber si actualmente estamos usando este campo. Preguntando al GPT de SuiteCRM dice que 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. 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. ¿Alguno sabéis si se está usando el envío de email a una persona para que confirme la autorización? En caso de que no se esté usando, la solución sería anular la propiedas audited del campo confirm_opt_in en metadata/email_addressesMetaData.php Si por el contrario, es una funcionalidad que está 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:
Esta solución tiene sentido ya que si un campo no existe en el bean es razonable pensar que no ha sido modificado. Me preocupa que el cambio se realiza en DBManager.php aunque me 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. |
|
Hola @ManuSinergiaCRM , |
|
Buenas, tras comentar el escenario con Enric, vemos que el caso de uso encontrado y su solución excede a este PR y decidimos crear un issue donde tratar dicha problemática: #545 y así poder continuar con la aprobación de este PR. |
ManuSinergiaCRM
requested review from
jordiSTIC and
enricsinergia
and removed request for
enricsinergia and
jordiSTIC
Descripción
Se observa que si un usuario tiene varias direcciones de correo, al pulsar el enlace de baja de una campaña de tipo correo electrónico, el CRM configura como Rehusado todas las cuentas de correo relacionadas con la persona o interesado y no solo la cuenta desde la que pulsó en el enlace de baja.
Comentándolo en el área de desarrollo, este comportamiento es razonable ya que la persona o interesado ha indicado que no quiere recibir más correos de campañas de email, por lo que la solución al PR tiene en cuenta esto y creará un registro por cada una de las direcciones de email en la tabla
_email_addresses_audit_Actualización
Auditar todos los emails rehusados ya sea en el proceso de baja de una campaña de tipo Email como desde la UI, donde se ha detectado que solo se audita el cambio en el checkbox de Rehusado del email principal. Es decir, si rehusamos todos los correos de una persona, solo se auditará el email que esté configurado como principal.
Cómo reproducir el problema
Baja de una campaña de tipo email
Rehusar correos desde la vista de edición