Cancellazione account GDPR: guida completa

Panoramica

Il modulo Cancellazione account GDPR dà ai tuoi clienti la possibilità di esercitare il diritto alla cancellazione (articolo 17 del GDPR) direttamente dalla loro area cliente, senza alcun intervento manuale da parte tua. Una richiesta innesca a cascata: conferma via email con token crittografico, anonimizzazione o cancellazione dell’account lato negozio, disiscrizione automatica su Mailchimp, Brevo e Mailjet, e scrittura di una prova del trattamento in un registro di audit.

Installazione

1. Accedi al back office PrestaShop.
2. Vai su Moduli → Gestore moduli, clicca su Carica un modulo e trascina lo ZIP dfaccountdelete-1.0.2.zip.
3. Il modulo viene installato e attivato automaticamente. Clicca su Configura.

L’installazione crea due tabelle: ps_dfad_log (registro GDPR) e ps_dfad_token (token di conferma via email). Registra il modulo sull’hook displayCustomerAccount, che aggiunge un blocco “Elimina il mio account” nell’area cliente.

Configurazione generale

La schermata di configurazione è divisa in quattro pannelli: Parametri generali, Mailchimp, Brevo, Mailjet. Ogni pannello si salva in modo indipendente.

Modalità di cancellazione

Scegli tra due modalità:

• Anonimizza (consigliata): i dati personali del cliente (nome, cognome, email, telefono, indirizzi, data di nascita) vengono sostituiti da valori anonimi. Gli ordini restano intatti per rispettare l’obbligo contabile di conservazione decennale.
• Elimina completamente se possibile: l’account viene cancellato del tutto se non esiste alcun ordine. Se esistono ordini, il modulo passa automaticamente alla modalità anonimizzazione per non compromettere lo storico legale.

Conferma via email obbligatoria

Attiva per impostazione predefinita (fortemente consigliata). Il cliente deve cliccare su un link ricevuto via email per convalidare la richiesta. Questo impedisce qualsiasi cancellazione accidentale o da parte di terzi che abbiano avuto accesso a una sessione aperta.

Durata di validità del token

In ore. 24 ore per impostazione predefinita. Oltre questa durata, il link nell’email scade e la richiesta viene annullata automaticamente.

Log

Attivi per impostazione predefinita. Il modulo scrive in ps_dfad_log ogni richiesta con soli dati pseudonimizzati: hash SHA-256 dell’email, hash SHA-256 dell’IP, identificativo cliente, modalità applicata, stato, provider contattati, user agent, identificativo negozio, marca temporale. Nessun dato personale viene conservato in chiaro.

Email amministratore notificato

Indirizzo che riceverà una notifica (solo hash dell’email, mai l’email in chiaro) a ogni cancellazione effettiva. Per impostazione predefinita, l’email del negozio.

Configurazione dei provider newsletter

Il modulo supporta di serie tre piattaforme newsletter. Ogni provider è disattivato per impostazione predefinita. Attiva solo quelli che usi.

Mailchimp

Compila:

• Chiave API: formato xxxxxxxxxxxx-us21. Il suffisso (-us21, -eu1, ecc.) è il datacenter Mailchimp. Il modulo lo rileva automaticamente.
• List ID (Audience ID): identificativo della tua audience principale. Lo trovi in Mailchimp da Audience → Settings → Audience name and defaults.
• Cancellazione permanente: attiva per impostazione predefinita. Usa l’endpoint POST /lists/{list_id}/members/{hash}/actions/delete-permanent che corrisponde al vero diritto all’oblio GDPR: l’email viene eliminata definitivamente e Mailchimp rifiuterà ogni futuro opt-in con quell’indirizzo. Se preferisci una semplice archiviazione (l’email potrà quindi reiscriversi in seguito), disattiva questa opzione.

Clicca su Testa la connessione per validare la configurazione. Se tutto è corretto vedrai il nome della tua audience.

Brevo (ex Sendinblue)

Compila:

• Chiave API v3: formato xkeysib-xxxxxx. La trovi in Brevo da Il mio account → SMTP e API → Chiavi API.
• List ID (facoltativo): se compilato, rimuove il contatto solo da quella lista. Se vuoto, elimina interamente il contatto (consigliato per il GDPR).

Endpoint usato: DELETE /v3/contacts/{email} per la cancellazione totale, oppure POST /v3/contacts/lists/{id}/contacts/remove per la rimozione da una lista.

Mailjet

Mailjet usa un’autenticazione Basic con due chiavi. Compila:

• API Key
• API Secret
• Contact List ID (facoltativo): se compilato, disiscrive solo da quella lista. Se vuoto, elimina il contatto tramite l’endpoint GDPR ufficiale di Mailjet.

Il flusso di cancellazione Mailjet è in due passaggi: lookup dell’identificativo contatto tramite GET /v3/REST/contact/{email}, poi DELETE /v4/contacts/{id} sull’endpoint GDPR. Il modulo gestisce automaticamente questo meccanismo.

Anonimizzazione o cancellazione: cosa scegliere?

Il GDPR impone il diritto alla cancellazione, ma il codice del commercio francese impone la conservazione dei documenti contabili per 10 anni. Questi due obblighi vengono conciliati dall’anonimizzazione, che è la posizione raccomandata dall’autorità garante francese.

Modalità anonimizzazione

Il modulo sostituisce in ps_customer:

• firstname diventa Anonymized
• lastname diventa Customer
• email diventa anon-{id_customer}-{hash}@anonymized.local
• passwd diventa un hash casuale (il cliente non potrà più connettersi)
• birthday diventa NULL
• note, website, ip_registration_newsletter vengono svuotati
• active diventa 0, deleted diventa 1

Per gli indirizzi:

• Gli indirizzi non usati da ordini vengono eliminati integralmente.
• Gli indirizzi usati da ordini vengono anonimizzati (firstname, lastname, address1, postcode, city, phone, ecc. sostituiti da valori neutri) e contrassegnati con deleted = 1.

Modalità cancellazione totale

Se il cliente non ha effettuato alcun ordine: eliminazione completa degli indirizzi e poi chiamata a Customer::delete(). Altrimenti: passaggio automatico alla modalità anonimizzazione. Nessuna opzione permette di forzare la cancellazione di un account con ordini, ed è voluto per ragioni legali.

Flusso completo di una richiesta

1. Il cliente va in Il mio account e clicca sul blocco “Elimina il mio account”.
2. Arriva su una pagina di conferma con un riquadro di avvertimento, un campo “Password” e una casella “Capisco che questa azione è irreversibile”.
3. Inserisce la password e spunta la casella. Il modulo verifica la password tramite la classe PrestaShop/Core/Crypto/Hashing.
4. Se la conferma via email è attiva, il modulo genera un token casuale di 32 byte (random_bytes(32)), lo converte in esadecimale su 64 caratteri, memorizza il suo hash SHA-256 in ps_dfad_token e invia un’email contenente il token in chiaro dentro un URL.
5. Il cliente riceve l’email e clicca sul link. Il modulo recupera il token dall’URL, ne calcola lo SHA-256 e verifica che esista nella tabella, che non sia scaduto e che non sia già stato consumato.
6. Il token viene contrassegnato come consumato (consumed_at = NOW()) per evitare qualsiasi riutilizzo.
7. Per ogni provider attivo (Mailchimp, Brevo, Mailjet), il modulo chiama l’API di cancellazione e registra il risultato (codice HTTP, messaggio) nel registro.
8. Il modulo ripulisce le tabelle PrestaShop: ps_emailsubscription, ps_newsletter, ps_cart, ps_cart_product, ps_wishlist, ps_compare, ps_customer_thread, ps_customer_message, ps_guest.
9. A seconda della modalità e della presenza di ordini, l’account viene anonimizzato o eliminato.
10. Una riga viene inserita in ps_dfad_log con lo stato done, la modalità realmente applicata e l’elenco dei risultati dei provider.
11. Un’email di notifica viene inviata all’amministratore configurato (solo hash dell’email).
12. Il cliente viene disconnesso e reindirizzato a una pagina di conferma.

Registro di trattamento GDPR

La schermata di configurazione mostra le ultime 30 richieste con:

• ID della richiesta
• Hash email troncato (primi 12 caratteri dello SHA-256)
• Modalità applicata (anonymize o delete)
• Stato (awaiting_confirm, done)
• Elenco dei provider e relativo codice di ritorno, per esempio mailchimp:OK(200) | brevo:OK(204) | mailjet:OK(200)
• Data e ora UTC

La tabella completa contiene anche: hash SHA-256 dell’IP, user agent troncato a 250 caratteri, identificativo negozio, note interne (presenza o meno di ordini).

Testare prima della messa in produzione

Procedura consigliata prima di attivare il modulo su un negozio di produzione:

1. Test delle connessioni ai provider: nel back office del modulo, clicca su Testa la connessione per ogni piattaforma attiva. Devi vedere un messaggio verde con il nome della tua audience o del tuo account. In caso di errore viene mostrato il messaggio HTTP esatto restituito dall’API.
2. Test del flusso completo su un account di prova:
   • Crea un account cliente con un vero indirizzo email che controlli.
   • Iscrivilo alla tua newsletter Mailchimp, Brevo o Mailjet manualmente oppure dal form del tuo negozio.
   • Verifica che compaia in ciascuna piattaforma.
   • Accedi a quell’account lato negozio e avvia la procedura di cancellazione.
   • Conferma tramite l’email ricevuta.
   • Verifica in ps_customer che l’account sia effettivamente anonimizzato.
   • Verifica in ciascuna piattaforma newsletter che l’email sia sparita.
   • Verifica la voce in ps_dfad_log.
3. Test del caso “cliente con ordine”: crea un account, effettua un ordine di prova (1 €), poi avvia la cancellazione in modalità “Elimina completamente”. Verifica che il modulo sia passato all’anonimizzazione e che l’ordine sia intatto ma con un indirizzo anonimo.

Estendere: aggiungere un nuovo provider

L’architettura segue un pattern Strategy. Aggiungere Sendgrid, Mailerlite, HubSpot, ActiveCampaign o qualsiasi altra piattaforma richiede solo la creazione di una classe.

Crea 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']];
    }
}

Registra la classe in DfAccountDeleteService::getProviders():

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

E carica la classe in cima a dfaccountdelete.php con un require_once. Il resto (pannello di configurazione nel back office, pulsante di test, integrazione nel flusso di cancellazione) va scritto in modo analogo ai provider esistenti.

FAQ e risoluzione dei problemi

Il cliente dice di non aver ricevuto l’email di conferma

Verifica: (1) la configurazione SMTP di PrestaShop è funzionante (invii altre email transazionali come le conferme d’ordine?), (2) l’email non è finita nello spam, (3) non è stato superato il termine di scadenza. Il cliente può rilanciare la procedura dal proprio account: il nuovo token invalida automaticamente i precedenti.

Una piattaforma newsletter restituisce un errore 401

La chiave API non è valida o è scaduta. Rigenerala nella piattaforma interessata e aggiornala nella configurazione del modulo. Usa il pulsante Testa la connessione per validarla subito.

Compare l’errore SQL “LIMIT 1 LIMIT 1”

Sei su una versione precedente alla 1.0.1. Aggiorna all’ultima versione: questo bug è stato corretto nella 1.0.1.

L’account non sembra anonimizzato: nome, cognome ed email originali sono ancora visibili

Sei su una versione precedente alla 1.0.2. La validazione interna di PrestaShop su Validate::isCustomerName() rifiutava il vecchio valore di lastname che conteneva il carattere # e delle cifre, facendo fallire silenziosamente l’aggiornamento. Aggiorna alla 1.0.2: l’upgrade automatico ripara anche gli account mal anonimizzati dalle versioni precedenti.

Come eliminare il registro GDPR alla disinstallazione?

La tabella ps_dfad_log viene volutamente conservata alla disinstallazione (prova del trattamento). Per eliminarla manualmente dopo la disinstallazione: DROP TABLE ps_dfad_log; DROP TABLE ps_dfad_token;.

Il modulo è compatibile con il mio modulo GDPR esistente (gdpr, psgdpr)?

Sì, i due moduli possono coesistere. Il modulo ufficiale PrestaShop psgdpr serve principalmente per l’esportazione dei dati e la gestione dei consensi; dfaccountdelete serve per la cancellazione effettiva degli account con integrazione newsletter. Non si pestano i piedi.

Il cliente può annullare dopo aver cliccato sul pulsante?

Sì, finché non ha cliccato sul link nell’email di conferma. Il token scade automaticamente dopo la durata configurata (24 ore per impostazione predefinita). In quella finestra l’account resta pienamente attivo. Se non fa nulla, la richiesta viene annullata.

Come aggiungere il blocco di cancellazione fuori da Il mio account?

Puoi creare un link diretto verso {shop_url}/{lang}/module/dfaccountdelete/delete da qualsiasi pagina (footer, pagina condizioni generali, ecc.). Se il visitatore non è connesso, verrà reindirizzato alla pagina di login e riportato poi alla pagina di cancellazione dopo l’autenticazione.

Versioni e changelog

1.0.2: correzione critica

• Fix: anonymizeCustomer() usava Customer::update() che passa da Validate::isCustomerName(). Questa validazione vieta le cifre e il carattere # in firstname e lastname, facendo fallire silenziosamente l’anonimizzazione del record ps_customer. Sostituito con un UPDATE SQL diretto che aggira la validazione.
• L’upgrade upgrade-1.0.2.php ripara retroattivamente gli account trattati dalle versioni precedenti rimasti non anonimizzati.

1.0.1: correzione

• Fix: tableExists() usava Db::getValue() che antepone automaticamente LIMIT 1. La query SHOW TABLES LIKE 'xxx' LIMIT 1 è un SQL non valido in MariaDB. Sostituito con executeS().

1.0.0: versione iniziale

• Compatibilità PrestaShop da 8.0 a 9.x
• Modalità anonimizzazione e modalità cancellazione totale
• Conferma via email con token SHA-256
• Integrazioni Mailchimp, Brevo, Mailjet
• Registro di trattamento GDPR
• Interfaccia e template email in FR, EN, ES, DE