Eliminación de cuenta RGPD — Guía completa

Visión general

El módulo Eliminación de cuenta RGPD da a sus clientes una forma de ejercer su derecho de supresión (Artículo 17 del RGPD) directamente desde su área de cliente, sin intervención manual por su parte. Una solicitud desencadena en cascada: confirmación por email con token criptográfico, anonimización o eliminación de la cuenta en la tienda, baja automática de Mailchimp, Brevo y Mailjet, y registro de una prueba de tratamiento en un registro de auditoría.

Instalación

1. Inicie sesión en el back office de PrestaShop.
2. Vaya a Módulos → Module Manager, haga clic en Subir un módulo y deposite el archivo dfaccountdelete-1.0.2.zip.
3. El módulo se instala y activa automáticamente. Haga clic en Configurar.

La instalación crea dos tablas: ps_dfad_log (registro RGPD) y ps_dfad_token (tokens de confirmación por email). Registra el módulo en el hook displayCustomerAccount, que añade un bloque «Eliminar mi cuenta» al área del cliente.

Configuración general

La pantalla de configuración está dividida en cuatro paneles: Configuración general, Mailchimp, Brevo, Mailjet. Cada panel se guarda independientemente.

Modo de eliminación

Elija entre dos modos:

• Anonimizar (recomendado): los datos personales del cliente (nombre, apellido, email, teléfono, direcciones, fecha de nacimiento) se reemplazan por valores anónimos. Los pedidos permanecen intactos para respetar la obligación contable de conservación durante 10 años (artículo L123-22 del Código de Comercio francés).
• Eliminar totalmente si es posible: la cuenta se borra completamente si no existen pedidos. Si existen pedidos, el módulo cambia automáticamente al modo de anonimización para no romper el historial legal.

Confirmación por email obligatoria

Activada por defecto (muy recomendado). El cliente debe hacer clic en un enlace recibido por email para validar su solicitud. Esto evita cualquier eliminación accidental o por parte de un tercero que haya accedido a una sesión abierta.

Duración de validez del token

En horas. 24 horas por defecto. Más allá de esta duración, el enlace en el email expira y la solicitud se cancela automáticamente.

Logs

Activados por defecto. El módulo escribe en ps_dfad_log cada solicitud con solo datos seudonimizados: hash SHA-256 del email, hash SHA-256 de la IP, ID de cliente, modo aplicado, estado, proveedores contactados, user agent, ID de tienda, marca de tiempo. No se conservan datos personales en texto claro.

Email de administrador notificado

Dirección que recibirá una notificación (solo hash del email, nunca el email en texto claro) en cada eliminación efectiva. Por defecto, el email de la tienda.

Configuración de los proveedores de newsletter

El módulo soporta tres plataformas de newsletter como estándar. Cada proveedor está desactivado por defecto. Active solo los que utilice.

Mailchimp

Complete:

• Clave API: formato xxxxxxxxxxxx-us21. El sufijo (-us21, -eu1, etc.) es el datacenter de Mailchimp. El módulo lo detecta automáticamente.
• List ID (Audience ID): identificador de su audiencia principal. Encontrable en Mailchimp en Audience → Settings → Audience name and defaults.
• Eliminación permanente: activada por defecto. Utiliza el endpoint POST /lists/{list_id}/members/{hash}/actions/delete-permanent que corresponde al verdadero derecho al olvido del RGPD: el email se elimina permanentemente y Mailchimp rechazará cualquier futuro opt-in con esta dirección. Si prefiere un simple archivado (el email puede volver a suscribirse más tarde), desactive esta opción.

Haga clic en Probar conexión para validar su configuración. Si todo está correcto, verá el nombre de su audiencia.

Brevo (antes Sendinblue)

Complete:

• Clave API v3: formato xkeysib-xxxxxx. Encontrable en Brevo en Mi cuenta → SMTP & API → Claves API.
• List ID (opcional): si se rellena, solo elimina el contacto de esta lista. Si se deja vacío, elimina el contacto completamente (recomendado para RGPD).

Endpoint utilizado: DELETE /v3/contacts/{email} para eliminación total, o POST /v3/contacts/lists/{id}/contacts/remove para eliminación de una lista.

Mailjet

Mailjet utiliza autenticación Basic con dos claves. Complete:

• API Key
• API Secret
• Contact List ID (opcional): si se rellena, da de baja solo de esta lista. Si se deja vacío, elimina el contacto mediante el endpoint RGPD oficial de Mailjet.

El flujo de eliminación de Mailjet es en dos pasos: búsqueda del identificador de contacto mediante GET /v3/REST/contact/{email}, luego DELETE /v4/contacts/{id} en el endpoint RGPD. El módulo gestiona esta mecánica automáticamente.

Anonimización o eliminación: ¿cuál elegir?

El RGPD impone el derecho al olvido, pero el Código de Comercio francés requiere la conservación de los documentos contables durante 10 años. Estas dos obligaciones se concilian mediante la anonimización, que es la posición recomendada por la CNIL (autoridad francesa de protección de datos).

Modo anonimización

El módulo reemplaza en ps_customer:

• firstname → Anonymized
• lastname → Customer
• email → anon-{id_customer}-{hash}@anonymized.local
• passwd → hash aleatorio (el cliente ya no podrá conectarse)
• birthday → NULL
• note, website, ip_registration_newsletter → vacío
• active → 0, deleted → 1

Para las direcciones:

• Las direcciones no utilizadas por pedidos se eliminan por completo.
• Las direcciones utilizadas por pedidos se anonimizan (firstname, lastname, address1, postcode, city, phone, etc. reemplazados por valores neutros) y marcadas deleted = 1.

Modo de eliminación total

Si el cliente no ha realizado ningún pedido: eliminación completa de direcciones, luego llamada a Customer::delete(). De lo contrario: cambio automático al modo de anonimización. Ninguna opción permite forzar la eliminación de una cuenta con pedidos — es intencional por razones legales.

Flujo completo de una solicitud

1. El cliente va a Mi cuenta y hace clic en el bloque «Eliminar mi cuenta».
2. Llega a una página de confirmación con un cuadro de advertencia, un campo «Contraseña» y una casilla «Entiendo que esta acción es irreversible».
3. Introduce su contraseña y marca la casilla. El módulo verifica la contraseña mediante la clase PrestaShop/Core/Crypto/Hashing.
4. Si la confirmación por email está activada, el módulo genera un token aleatorio de 32 bytes (random_bytes(32)), lo convierte a hexadecimal de 64 caracteres, almacena su hash SHA-256 en ps_dfad_token, y envía un email que contiene el token en texto claro en una URL.
5. El cliente recibe el email y hace clic en el enlace. El módulo recupera el token de la URL, calcula su SHA-256, y verifica que existe en la tabla, no ha expirado y no se ha consumido.
6. El token se marca como consumido (consumed_at = NOW()) para evitar reutilización.
7. Para cada proveedor activado (Mailchimp, Brevo, Mailjet), el módulo llama a la API de eliminación y registra el resultado (código HTTP, mensaje) en el registro.
8. El módulo limpia las tablas de PrestaShop: ps_emailsubscription, ps_newsletter, ps_cart, ps_cart_product, ps_wishlist, ps_compare, ps_customer_thread, ps_customer_message, ps_guest.
9. Según el modo y la presencia de pedidos, la cuenta se anonimiza o se elimina.
10. Se inserta una fila en ps_dfad_log con estado done, el modo realmente aplicado y la lista de resultados de los proveedores.
11. Se envía un email de notificación al administrador configurado (solo hash del email).
12. El cliente se desconecta y es redirigido a una página de confirmación.

Registro de tratamiento RGPD

La pantalla de configuración muestra las últimas 30 solicitudes con:

• ID de la solicitud
• Hash de email truncado (primeros 12 caracteres del SHA-256)
• Modo aplicado (anonymize / delete)
• Estado (awaiting_confirm, done)
• Lista de proveedores y su código de retorno, por ejemplo mailchimp:OK(200) | brevo:OK(204) | mailjet:OK(200)
• Fecha y hora UTC

La tabla completa también contiene: hash SHA-256 de la IP, user agent truncado a 250 caracteres, ID de tienda, notas internas (presencia o no de pedidos).

Pruebas antes de pasar a producción

Procedimiento recomendado antes de activar el módulo en una tienda en producción:

1. Pruebe las conexiones de los proveedores: en el BO del módulo, haga clic en Probar conexión para cada plataforma activada. Debería ver un mensaje verde con el nombre de su audiencia/cuenta. En caso de error, se muestra el mensaje HTTP exacto devuelto por la API.
2. Pruebe el flujo completo en una cuenta de prueba:
   • Cree una cuenta de cliente con una dirección de email real que controle.
   • Suscríbala a su newsletter de Mailchimp/Brevo/Mailjet manualmente, o mediante el formulario de su tienda.
   • Compruebe que aparece en cada plataforma.
   • Inicie sesión con esta cuenta en la tienda e inicie el procedimiento de eliminación.
   • Confirme mediante el email recibido.
   • Compruebe en ps_customer que la cuenta está correctamente anonimizada.
   • Compruebe en cada plataforma de newsletter que el email ha desaparecido.
   • Compruebe la entrada en ps_dfad_log.
3. Pruebe el caso «cliente con pedido»: cree una cuenta, realice un pedido de prueba (1€), luego inicie la eliminación en modo «Eliminar totalmente». Compruebe que el módulo ha cambiado correctamente a anonimización y que el pedido está intacto pero con una dirección anónima.

Extensión: añadir un nuevo proveedor

La arquitectura sigue un patrón Strategy. Añadir Sendgrid, Mailerlite, HubSpot, ActiveCampaign o cualquier otra plataforma solo requiere crear una clase.

Cree classes/Provider/SendgridProvider.php:

class DfAccountDelete_SendgridProvider extends DfAccountDelete_AbstractProvider
{
    public function getKey() { return 'sendgrid'; }

    public function isEnabled()
    {
        return (bool) Configuration::get('DFAD_SG_ENABLED')
            && Configuration::get('DFAD_SG_API_KEY');
    }

    public function deleteSubscriber($email)
    {
        $headers = ['Authorization: Bearer ' . Configuration::get('DFAD_SG_API_KEY')];
        $url = 'https://api.sendgrid.com/v3/marketing/contacts?emails=' . rawurlencode($email);
        $res = $this->http('DELETE', $url, $headers);
        return ['ok' => $res['ok'], 'status' => $res['status'], 'message' => $res['message']];
    }

    public function testConnection()
    {
        $headers = ['Authorization: Bearer ' . Configuration::get('DFAD_SG_API_KEY')];
        $res = $this->http('GET', 'https://api.sendgrid.com/v3/scopes', $headers);
        return ['ok' => $res['ok'], 'status' => $res['status'], 'message' => $res['message']];
    }
}

Referencie la clase en DfAccountDeleteService::getProviders():

public function getProviders()
{
    return [
        new DfAccountDelete_MailchimpProvider(),
        new DfAccountDelete_BrevoProvider(),
        new DfAccountDelete_MailjetProvider(),
        new DfAccountDelete_SendgridProvider(), // nuevo
    ];
}

Y cargue la clase en la parte superior de dfaccountdelete.php con un require_once. El resto (panel de configuración del BO, botón de prueba, integración en el flujo de eliminación) debe codificarse de forma similar a los proveedores existentes.

Preguntas frecuentes y resolución de problemas

El cliente dice que no ha recibido el email de confirmación

Compruebe: (1) ¿está funcionando la configuración SMTP de PrestaShop (envía otros emails transaccionales como las confirmaciones de pedido?), (2) ¿no está el email en su spam?, (3) ¿no se ha alcanzado el tiempo de expiración? El cliente puede volver a iniciar el procedimiento desde su cuenta — el nuevo token invalida automáticamente los anteriores.

Una plataforma de newsletter devuelve un error 401

La clave API es inválida o ha expirado. Regenérela en la plataforma correspondiente y actualícela en la configuración del módulo. Use el botón Probar conexión para validar inmediatamente.

Aparece el error SQL «LIMIT 1 LIMIT 1»

Está en una versión anterior a 1.0.1. Actualice a la última versión: este error se corrigió en 1.0.1.

La cuenta no parece anonimizada: el nombre/apellido/email originales siguen siendo visibles

Está en una versión anterior a 1.0.2. La validación interna de PrestaShop en Validate::isCustomerName() rechazaba el antiguo valor de lastname que contenía el carácter # y dígitos, lo que provocaba un fallo silencioso de la actualización. Actualice a 1.0.2: la actualización automática también repara las cuentas mal anonimizadas de las versiones anteriores.

¿Cómo eliminar el registro RGPD al desinstalar?

La tabla ps_dfad_log se conserva intencionalmente al desinstalar (prueba del tratamiento). Para eliminarla manualmente tras la desinstalación: DROP TABLE ps_dfad_log; DROP TABLE ps_dfad_token;.

¿Es el módulo compatible con mi módulo RGPD existente (gdpr, psgdpr)?

Sí, los dos módulos pueden coexistir. El módulo oficial de PrestaShop psgdpr se utiliza principalmente para la exportación de datos y la gestión del consentimiento; dfaccountdelete se utiliza para la eliminación efectiva de cuentas con integración de newsletter. No se pisan los pies.

¿Puede el cliente cancelar después de hacer clic en el botón?

Sí, mientras no haga clic en el enlace del email de confirmación. El token expira automáticamente tras la duración configurada (24 horas por defecto). Durante esta ventana, la cuenta permanece completamente activa. Si no hace nada, la solicitud se cancela.

¿Cómo añadir el bloque de eliminación en otro lugar que no sea Mi cuenta?

Puede crear un enlace directo a {shop_url}/{lang}/module/dfaccountdelete/delete desde cualquier página (pie de página, página de términos y condiciones, etc.). Si el visitante no ha iniciado sesión, será redirigido a la página de inicio de sesión con un retorno a la página de eliminación tras la autenticación.

Versiones y changelog

1.0.2 — corrección crítica

• Fix: anonymizeCustomer() utilizaba Customer::update() que pasa por Validate::isCustomerName(). Esta validación prohíbe los dígitos y el carácter # en firstname/lastname, lo que provocaba que la anonimización del registro ps_customer fallara silenciosamente. Reemplazado por un UPDATE SQL directo que omite la validación.
• La actualización upgrade-1.0.2.php repara retroactivamente las cuentas tratadas por versiones anteriores que permanecían no anonimizadas.

1.0.1 — corrección

• Fix: tableExists() utilizaba Db::getValue() que añade automáticamente LIMIT 1. La consulta SHOW TABLES LIKE 'xxx' LIMIT 1 es SQL inválido en MariaDB. Reemplazado por executeS().

1.0.0 — versión inicial

• Compatibilidad con PrestaShop 8.0 hasta 9.x
• Modo anonimización y modo eliminación total
• Confirmación por email con token SHA-256
• Integraciones Mailchimp, Brevo, Mailjet
• Registro de tratamiento RGPD
• Interfaz y plantillas de email en FR, EN, ES, DE