Integrazione tecnica per CTO

Piano in 4 step per migrare un’applicazione Yii Legacy (PHP < 7.4) verso PHP 8.x, minimizzando i downtime e garantendo la retrocompatibilità delle funzioni core. Approccio step-by-step come per CLOe.

Step 1 – Inventario e isolamento. Mappare codice e dipendenze: estensioni PHP deprecate/rimosse, librerie non compatibili con 8.x, utilizzo di costrutti deprecati (costruttori con nome della classe, each(), create_function(), parametri passati per riferimento implicito). Introdurre un layer di compatibilità (polyfill o wrapper) solo per le parti critiche e delimitare i moduli da migrare per primi (auth, presenze, export).

Step 2 – Ambiente parallelo e primo target 7.4. Allestire un ambiente (staging/mirror) identico al production. Portare l’applicazione su PHP 7.4 con Yii 1.x (o bridge verso Yii2 se già previsto), correggendo deprecation e type hints dove necessario. Obiettivo: zero breaking change per le funzioni core; test funzionali e regression su flussi critici (login, timbrature, report). CLOe ha seguito questo passaggio mantenendo le stesse API e contratti dati.

Step 3 – Upgrade a PHP 8.x e type safety. Eseguire l’upgrade a PHP 8.0/8.1 (o 8.2) nell’ambiente parallelo. Introdurre tipizzazione progressiva (parametri e return type), sostituire costrutti obsoleti con equivalenti 8.x (union types, named arguments dove utile, attributi se si pianifica evoluzione verso Yii2/3). Validare estensioni e dipendenze (Composer) e aggiornare solo ciò che è necessario; il resto resta invariato per ridurre il rischio.

Step 4 – Cut-over e rollback pianificato. Definire una finestra di cut-over con backup e script di rollback. Eseguire il passaggio in produzione, monitorare errori e performance (log, APM, health check). Mantenere la possibilità di ripristino rapido alla versione precedente. Documentare le modifiche e le configurazioni (PHP, web server, env) per ripetibilità e per futuri upgrade.

L’approccio step-by-step usato per CLOe permette di non “riscrivere tutto in un colpo”, di conservare la stabilità del core e di allineare progressivamente il codice agli standard PHP 8.x e alla sicurezza dei dati.

CLOe gestisce il geofencing nella WebApp in modo da non memorizzare la posizione continua dell’utente e da minimizzare i dati di geolocalizzazione trattati, in linea con il principio di minimizzazione (GDPR art. 5).

Flusso. (1) La WebApp richiede una tantum il permesso di geolocalizzazione e ottiene coordinate e accuratezza solo nel momento della timbratura (entrata/uscita), senza tracciamento continuo. (2) Vengono inviate al server solo le coordinate del singolo evento di timbratura (timestamp, lat/long, accuracy). (3) Il server calcola la distanza (o il containment) rispetto ai perimetri autorizzati (geofence); l’esito è binario: “dentro/fuori” (e eventuale geofence_id). Il calcolo avviene solo sul server, con logica centralizzata e auditabile. (4) In database vengono memorizzati: identificativo utente, timestamp della timbratura, esito del geofence (es. status_geofence: inside/outside). Le coordinate grezze (lat/long) possono essere non memorizzate o conservate solo per il tempo strettamente necessario (es. contestazione) e poi cancellate o anonimizzate.

Conformità. Minimizzazione (nessun tracciamento continuo; dati di posizione limitati all’istante della timbratura). Finalità: verifica che la timbratura avvenga in prossimità di un’area consentita. Base giuridica: tipicamente obblighi contrattuali/legali (controllo presenze), da indicare in informativa e DPR. Sicurezza: HTTPS, accessi e log solo per ruoli autorizzati, retention limitata per le coordinate.

In sintesi: il geofencing in CLOe è progettato come verifica puntuale (match con il perimetro autorizzato) con calcolo lato server e senza memorizzazione della posizione continua, riducendo il rischio per la privacy e allineando il trattamento ai principi GDPR.