# 🔄 REFACTORING LOG — Gestionale Ordini Benza Changelog. Il **refactoring è concluso** (gestionale in produzione su Aruba dall'11/07/2026). Da qui in poi si registrano solo **fix bug / modifiche** della fase di manutenzione. 📦 **Storia completa del refactor (2024→11/07/2026):** `docs/archive/REFACTORING_LOG_completo.md` ## File correlati - `PROJECT_INFO.md` — stack, brand, struttura, helper PHP/JS, pattern API - `DOCUMENTAZIONE_API_JWT.md` — sistema API e JWT - `SECURITY_AUDIT.md` — audit sicurezza + remediation - `db_connection.md` — credenziali DB consultazione (SOLO LETTURA) - `sql/` — migration SQL numerate (eseguite manualmente dall'utente) - `archive/` — doc storici del refactor (analisi iniziale, preventivo, template CMS, log completo) --- ## MANUTENZIONE (post go-live) ### FEATURE (extra) — "Da installare" con data di installazione (15/10/2026) Richiesta di Benza: segnare gli ordini con un'installazione da fare e ritrovarli in una scheda dedicata. Il vecchio gestionale non aveva niente di simile: è un lavoro extra (il primo dopo il saldo di ottobre). - **DB — migration `044_or_ordini_da_installare.sql`:** `or_ordini.da_installare` (TINYINT, default 0) e `data_installazione` (DATE, NULL). Default per non toccare sito_26 e prev_vasche, che creano ordini senza conoscerle. **Va eseguita prima del deploy:** `Ordine::update()` scrive tutte le colonne insieme. - **Tutto manuale**, a differenza di "Da spedire": nessuno stato tocca questi campi. - **Scheda ordine:** casella "Da installare" sotto "Da spedire" + campo data. Si salvano da soli come gli altri flag (`salvaFlagOrdine`, nuova `salvaDataInstallazione`). La data compare con la spunta ("Prevista il"); togliendo la spunta **resta salvata e visibile** come data effettiva ("Installato il"). Il campo data manda `change` anche a metà digitazione dell'anno: attesa di 600 ms e anni < 2000 scartati. - **Lista Ordini:** scheda "Da installare" col suo contatore (`conteggi.php`), indipendente dallo stato come "Da spedire". La colonna Data diventa "Installazione": vuota se non indicata, **grassetto se oggi, rossa se passata**. Ordinata per scadenza: prima le più vicine, in fondo quelle senza data (`Ordine::read()`, `$orderBy`). - **API:** `read.php`/`read_one.php` restituiscono i due campi; `update.php` li accetta (data validata `Y-m-d`, vuota → NULL) e li scrive nel Log Attività. ### FIX — Fatturazione: di nuovo possibile registrare importi negativi (note di credito) (12/10/2026) Benza non riusciva a registrare le note di credito: il campo Importo rifiutava i valori sotto zero. - **Regressione nostra:** il vecchio gestionale (`fatturazione.php`) non aveva nessun minimo, e in produzione ci sono già **58 fatture negative** (la più grossa -101.500 €). Nel rifacimento i due campi avevano preso `min="0"`. - **L'unico blocco era quello:** `or_fatturazioni.importo` è `decimal(10,2)` con segno, l'API usa `floatval()` senza controlli sul segno, e chi somma le fatture (totali, dashboard, cassa) le tratta già come sottrazioni, visto che i 58 negativi esistono da prima. - **Fix:** tolto `min="0"` dal campo della nuova fattura e da quello della modifica (`fatturazione.php`). - **Test sul NAS** (ordine 12842): fattura "TEST-NC" da -250,50 inviata dal form, salvata e mostrata con -305,61 € con IVA; poi eliminata. ### FIX — Ricerca Avanzata, campo "Luogo": con più parole non trovava niente (25/09/2026) Segnalazione: "il campo Luogo sembra cercare solo nell'indirizzo di fatturazione o solo in quello di spedizione". - **Verificato che non è così:** la condizione copriva già i dieci campi di `or_clienti` (via, cap, comune, prov, stato e le varianti `s_*`). In produzione, cliente 7874 (fatturazione Poggiomarino 80040, spedizione Avellino 83044): tutte e quattro le ricerche singole restituiscono tutti i suoi 12 ordini. Codice di produzione confrontato via FTP con il repo: identico. - **Il bug vero, stesso sintomo:** la frase intera veniva cercata dentro **un solo** campo. "Avellino 83044", "Avellino (AV)", "Poggiomarino, 80040" davano **0 risultati**, perché città, CAP e provincia stanno in colonne diverse. Chi scriveva due informazioni insieme vedeva sparire ordini che c'erano. - **Fix** (`api/objects/ordine.php`): nuovo `filtroLuogo()`, usato sia da `read()` sia da `count()` (prima erano due copie identiche del blocco). Il testo si spezza in parole (spazi, virgole, punti e virgola, parentesi) e **ogni parola deve comparire in almeno uno dei dieci campi**. Una parola sola dà lo stesso risultato di prima. Tetto a 8 parole (ciascuna sono 10 LIKE). - **Test sul NAS** (cliente 5928, Bologna 40122 / Novellara 42023): `Bologna 40122`, `Novellara 42023`, `Novellara, 42023` passano da 0 a 36 ordini; `Novellara (RE)` 37; `Bologna Novellara` 36 (fatturazione e spedizione mescolate: stesso cliente); `Bologna Milano` resta 0. Parole singole invariate (98 e 38). ### FIX — Il pagamento nasceva con la data dello stato creato prima (24/09/2026) Benza ha mostrato il problema di persona a Paolo, che però non riusciva a rifarlo: l'ordine **#12746**, pagamento registrato la mattina del 24/09, compariva con la data del "Ricevuto ordine" del 19/09. **Non era il telefono di Davide: il dato sbagliato arrivava davvero al server.** - **Causa:** il pannello "Avanzate" ha **un solo** campo data (`edit_data_ora`) per tutta la pagina, e resta valorizzato dopo il salvataggio. Lo azzera `setupAvanzateCreazione()`, che però la chiamano solo le modal che usano Avanzate in creazione (Generico, Preventivo, Ricevuto, Spedizione, Problema, Chiudi): **non il Pagamento**, che ha un campo data suo. In `salvaStato()` la data di Avanzate veniva presa ogni volta che il formData non ne portava già una. - **Perché è emerso solo adesso:** dal fix del 13/08/2026 la modal Pagamento manda la sua data **solo se l'operatore la tocca** (altrimenti lascia al backend l'ora coi secondi). Data non toccata → niente `data_ora` nel formData → `salvaStato` ripescava il valore rimasto in `edit_data_ora`. Prima il Pagamento la mandava sempre e il guard `!formData.has('data_ora')` bastava. - **La sequenza, dal Log Attività:** 07:09:04 Davide crea il "Ricevuto ordine" retrodatandolo da Avanzate al 19/09 07:08 → 07:18:50 crea il Pagamento senza toccarne la data, che nasce con **19/09 07:08:00** (il primo log di modifica lo dice: `data_ora {da: "2026-09-19 07:08:00"}`) → 07:22-07:24, sette modifiche per rimetterla a posto. Paolo non lo riproduceva perché registrava il pagamento senza aver prima creato uno stato con data personalizzata. - **Fix** (`salvaStato`, `ordine.js`): la data di Avanzate si usa solo se quel pannello appartiene alla creazione in corso — `edit_cod_stato` vuoto **e** `edit_cod_categoria` uguale alla `cod_categoria` del formData. Copre anche il caso gemello (creare un pagamento subito dopo averne modificato un altro, dove la sola categoria coinciderebbe). - **Verificato sul NAS** rifacendo la sequenza: generico retrodatato al 19/09 07:08, poi pagamento senza toccare la data → salvato `2026-09-24 09:14:10`, ora vera coi secondi. Stati di prova eliminati dall'interfaccia (mai DELETE SQL: i totali si ricalcolano solo dal percorso API). - **Dato in produzione:** il pagamento #71448 è stato riportato all'ora reale di creazione (07:18:50) dall'interfaccia, usando il campo secondi di Avanzate. ### FEATURE — Allegati di stato col nome originale, a schermo e nel download (14/09/2026) Benza: nell'elenco allegati sotto ogni stato il nome era lunghissimo (`ord-13011-stato-71276-2-VenditaaldettaglioVEN-4195-2f479fad.pdf`) e scaricando un file per girarlo a un cliente andava rinominato ogni volta. - **Due cause.** (1) `getFileName()` in `ordine.js` toglieva il prefisso solo nel formato del vecchio gestionale (`ord-N-stato-N_N_nome`, underscore): il formato di `uploadNomeSicuro()` usa i trattini e ha il suffisso casuale, quindi non prendeva e mostrava tutto. (2) Il nome originale **non veniva salvato**: `or_allegati` aveva solo `file`, e la sanificazione toglie spazi e punti ("Vendita al dettaglio VEN-4195.pdf" → `VenditaaldettaglioVEN-4195`). - **Migration 043** (`or_allegati.nome_originale` VARCHAR 255, eseguita da Paolo su NAS e Aruba il 14/09): salvato nei tre upload (`stati.php` POST e PUT, `email/save.php`) e portato dietro nella **copia stato**. Il nome su disco resta quello di sempre. - **Helper condivisi** in `api/config/allegati_nomi.php` (incluso da `funzioni_api.php`): `nomeOriginaleAllegato()` (basename, via caratteri di controllo e virgolette, 255) e `nomeAllegatoVisibile($file, $nome_originale)` (l'originale se c'è; altrimenti il nome su disco senza codici e suffisso, in entrambi i formati). File a parte perché `funzioni_api.php` ridefinisce `my_encrypt`/`my_decrypt` di `includes/helpers.php` e una pagina non può includerlo. - **Il backend restituisce già `nome`** per ogni allegato (`stati.php` GET): il JS lo usa nelle tre viste (timeline, modal "Allegati ordine", modal di modifica) con `escapeHtml` — il nome originale può contenere di tutto. `getFileName()` aggiornata al formato nuovo come ripiego. - **`allegato.php`** (nuovo, root, sessione come le pagine): serve il file con `Content-Disposition` col nome pulito (`filename` ASCII + `filename*` UTF-8). PDF, immagini, video e audio **inline** (si aprono nella scheda come prima, e salvando dal viewer il nome proposto è quello pulito); tutto il resto `attachment`. **MIME da mappa fissa per estensione, mai da `finfo`** (segnalazione della revisione automatica: un `.jpg` che contiene HTML sarebbe stato servito come `text/html`), più `nosniff` e `CSP: sandbox`. Sessione chiusa prima del `readfile`. `uploads/allegati/` resta raggiungibile com'era. - **Zip** (`allegati_zip.php`): nomi puliti; due omonimi diventano `Nome.pdf` e `Nome (2).pdf`. - **Test sul NAS** (stato di prova poi eliminato dall'interfaccia): upload di due "Fattura n. 12 società (copia).pdf" → a schermo il nome originale in tutte e tre le viste, su disco `ord-12739-stato-70288-1-Fatturan12societcopia-72f2afcf.pdf`, header `inline; filename*=UTF-8''Fattura%20n.%2012%20societ%C3%A0%20(copia).pdf`, PDF aperto nel viewer con CSP sandbox, zip con le due entry deduplicate. Senza sessione `allegato.php` rimanda a `login.php?vai=…`. - **Per i file già caricati** non c'è modo di recuperare il nome originale: si vedono e si scaricano col nome su disco senza i codici (`VenditaaldettaglioVEN-4195.pdf`). ### FIX — Email con accenti: "societ?" a schermo e testo troncato nello stato (10/09/2026) Segnalato da Benza su una mail di Gianluca Scaglione (F.lli Di Martino SpA): a schermo si leggeva "per la nostra societ**?**", e salvandola in uno stato dell'ordine **il testo si fermava lì**. Lo stato #71213 (ordine 13000, salvato da Paride alle 16:24) era lungo 159 caratteri e finiva esatto su "per la nostra societ". - **Causa:** `ImapReader::decodeBody()` scioglieva solo il transfer-encoding (base64 / quoted-printable) ma **non convertiva il charset** della parte MIME. Una mail in ISO-8859-1 o Windows-1252 arrivava coi byte accentati grezzi (`0xE0` per `à`). Gli header (oggetto, mittente) la conversione ce l'avevano già in `decodeMime`, il corpo no. - **Perché due sintomi diversi:** a schermo il corpo passa da `json_encode(..., JSON_INVALID_UTF8_SUBSTITUTE)` in `api/email/imap.php`, che rimpiazza i byte non validi con `?`. Al salvataggio invece `api/email/save.php` prende `$email['body']` **direttamente dal reader**, senza passare da JSON, e lo scrive in `or_stati.descrizione` su una connessione `utf8mb4`: MySQL taglia la stringa al primo byte non valido, in silenzio. - **Fix:** nuovo `testoInUtf8($testo, $part)` in `includes/ImapReader.php`, applicato in `extractBody()` a **entrambi** i rami (mail semplice e multipart). Legge il charset dai `parameters` della struttura MIME; se manca o è dichiarato a sproposito ripiega su Latin-1, dove ogni byte è valido, così l'uscita è sempre UTF-8 buono. Un charset sconosciuto fa lanciare `ValueError` a `mb_convert_encoding` su PHP 8 (l'`@` non basta): è dentro un try/catch. **Non** tocca `downloadAttachment()`, che è binario. - Verificato su 6 casi (latin1 dichiarato, latin1 senza charset, windows-1252 con € e virgolette curve, UTF-8 già buono, charset inventato, charset dichiarato UTF-8 ma in realtà latin1): tutti convertiti giusti. In produzione la mail ora mostra "società F.lli Di Martino SpA" e "fattibilità". Sul NAS non è testabile: manca php-imap. - **Gli stati già troncati restano troncati**, il testo perduto non è nel DB: vanno risalvati dalla mail originale e cancellato il vecchio. ### FIX — Via l'icona verde dalla checkbox "Problema già risolto" (10/09/2026) Nella modal "Problema post-vendita" la label della checkbox aveva davanti un ``, che finiva incastrato fra la casella e il testo. Rimosso, resta la sola scritta (`ordine.php`). ### FIX — Importi da incassare, grassetto sì e grassetto no (07/09/2026) Nella lista Ordini due righe con la stessa identica frase ("In attesa pagamento di X €") mostravano l'importo una in grassetto e una no. Non era casuale: `getStatoHtml()` arriva a quella frase da **due strade diverse** e solo una aveva `fw-bold`. Il ramo **cat 5** (ultimo stato "Ricevuto ordine") scriveva `stato-rosso`, il ramo di ripiego per gli ordini senza stati scriveva `stato-rosso fw-bold`. In pagina si contavano 6 importi in grassetto e 5 no. - Uniformato al **grassetto**, che era già la scelta di tutti gli altri rami ("Da pagare", "Da saldare ancora", "Ordine spedito, da saldare"): l'importo ancora da incassare è il numero che si cerca a colpo d'occhio. - Corretto anche il ramo **cat 7 con spedizione inviata** ("Ordine spedito, da saldare X"), che aveva la stessa incoerenza, e le due gemelle in **`archivio.js`**: la funzione è duplicata nelle due pagine, toccarne una sola avrebbe spostato il problema invece di chiuderlo. - Verificato in pagina: gli ordini #11172 e #12850 ora hanno lo stesso stile, e degli 11 stati rossi visibili 10 sono in grassetto. L'unico rimasto senza è "Problema da risolvere!", che non è un importo. - **Lasciato com'è** il ramo cat 7 senza spedizione ("Ordine da spedire e da saldare X"): lì è la frase intera a essere rossa, non l'importo isolato, e metterla in grassetto cambierebbe il peso della riga. Se si vuole uniformare anche quella, è una scelta grafica da fare a parte. ### FIX — Il login richiesto ogni volta aprendo un link da WhatsApp o dalla posta (07/09/2026) Benza se ne lamentava da tempo: aprendo un link a una pagina del gestionale da WhatsApp o da un'email, il browser chiedeva l'accesso **ogni volta**, per quanto spuntasse "Ricordami". Non è il telefono e non è un'impostazione sua: era il nostro cookie. - **Causa:** il cookie di sessione `gest_adm_login_string` era `SameSite=Strict`. Con Strict il browser **non manda il cookie** quando la navigazione arriva da un altro sito, ed è esattamente il caso del click su un link in WhatsApp o nella posta. Il cookie c'era ed era valido, semplicemente non veniva inviato: il gestionale vedeva una richiesta senza sessione e mostrava il login. Da lì in poi la navigazione è interna, quindi tutto funzionava e il problema sembrava capriccioso. - **Fix:** `SameSite=Lax` (`login-db.php`). Lax manda il cookie sulle navigazioni normali di primo livello (il click su un link), ma continua a **non** mandarlo sulle richieste cross-site che scrivono. La protezione CSRF resta perché tutte le nostre scritture passano da POST/PUT/DELETE con corpo JSON o FormData, mai da una GET. - **`Ricordami` non c'entrava** ed è rimasto com'era: decide solo se il cookie dura 30 giorni o fino alla chiusura del browser. ### FEATURE — Dopo l'accesso si torna alla pagina che si stava aprendo (07/09/2026) Prima si finiva sempre sulla lista ordini, anche arrivando da un link a un ordine preciso: bisognava ricercarselo a mano. - `includes/auth.php` allega la pagina richiesta al dirottamento verso il login (`login.php?vai=`), **solo per le GET**: una POST non ha senso ripeterla dopo l'accesso. - `login.php` ne tiene **solo il nome del file e la query**, e accetta la destinazione unicamente se è un `.php` esistente in quella cartella e non è il login stesso. Così nessun link costruito ad arte può spedire l'utente su un altro sito subito dopo l'accesso (open redirect), e un link vecchio a una pagina rimossa non lo lascia su un 404: si ripiega sulla lista ordini. - Verificato sul NAS senza credenziali, via `curl`: pagina protetta → `login.php?vai=…`; con destinazione valida → `ordine.php?cod=12842`; `https://sito-esterno` → `ordini.php`; `//sito-esterno/x.php` → `ordini.php`; `login.php` (ciclo) → `ordini.php`; nessun parametro → `ordini.php`. ### FIX — La home non scorreva su Chrome Android: html e body erano due scroller (07/09/2026) **Causa trovata**, con le misure prese dal telefono di Benza (pannello `?diag=scroll26`, poi rimosso). Nel media query mobile c'era `html, body { overflow-x: hidden; max-width: 100vw }`. Il CSS non ammette un asse `hidden` e l'altro `visible`: `overflow-y` diventa **`auto` su tutti e due**, quindi html e body si ritrovano a essere **due contenitori di scroll annidati**. Chrome Android aggancia il gesto verticale al **body**, che è alto quanto tutto il contenuto e non ha niente da scorrere, e la pagina resta immobile. Firefox e Safari passano invece il gesto al documento: da qui il "solo su Chrome". - **La prova nei dati del suo telefono:** `HTML ox=hidden oy=auto` con **713px** da scorrere, `BODY ox=hidden oy=auto` con `clientHeight === scrollHeight` (niente da scorrere), `scrollingElement: HTML`, e soprattutto **`scrollTo(0,300)` funzionava** (si muoveva da 656 a 401) mentre il dito non otteneva nulla: la pagina era scrollabile, era il gesto a finire nel posto sbagliato. Coerente anche col gesto che Benza aveva scoperto per caso (trascinare prima in giù e poi in su): invertendo la direzione Chrome riassegna il gesto. - **Fix:** tolto `overflow-x: hidden` e `max-width: 100vw` da `html, body`. La protezione contro lo sforamento orizzontale resta su `#page-content-wrapper`, che ce l'aveva già, e non serviva comunque: il pannello riportava `scrollW === clientW`, **la pagina non sforava di un pixel**. - **Perché solo la pagina Ordini:** la regola valeva ovunque, ma è lì che il body fa da contenitore diretto del gesto su quasi tutto lo schermo. Altrove il dito cade su elementi che lasciano passare lo scroll al documento. - `overscroll-behavior: none` su html/body **resta**: non crea scroller, disabilita solo il pull-to-refresh, ed è una scelta voluta. - **Secondo giro, stessa causa un livello più in basso.** Con html/body sistemati la pagina ancora non si muoveva, e la traccia del gesto ha mostrato la catena sotto il dito: `TD.cell-cliente` (overflow hidden per l'ellissi) → `.table-responsive` → **`#page-content-wrapper` con `oy=auto` e `dY=0`**, cioè un contenitore di scroll che copre tutta la pagina e non ha niente da scorrere. Sempre l'effetto di `overflow-x: hidden` che promuove l'asse verticale ad `auto`. - **`overflow: clip` invece di `hidden`** su `#page-content-wrapper` e sulle celle troncate della tabella: taglia allo stesso modo, mantiene `text-overflow: ellipsis`, ma **non crea un contenitore di scroll**. Misurato in Chrome: `hidden` → `oy=auto`, `clip` → `oy=visible`. La riga `overflow: hidden` resta prima di `clip` come ripiego per i browser che non lo conoscono (Safari < 16). - **Regola generale per il progetto:** `overflow: hidden` usato solo per *tagliare* va sostituito con `clip`, altrimenti si semina la pagina di scroller invisibili che su Chrome Android si mangiano il gesto. ### FIX — La home non scorreva su Chrome Android: la tabella si prendeva il gesto (07/09/2026) Video di Benza e dettagli decisivi: **solo la pagina Ordini**, **solo Chrome su smartphone** (altri browser sullo stesso telefono a posto, altre pagine del gestionale a posto), il touch funziona (i tocchi rispondono) e la tabella si scorre in orizzontale. Niente a che vedere con la rete di sicurezza sui modal messa poco prima. - **Causa:** Bootstrap dà a `.table-responsive` `overflow-x: auto`, e il CSS promuove da sé `overflow-y` da `visible` ad `auto` (misurato: `overflowY: auto` su tutti quei contenitori). Il contenitore è quindi uno scroller **anche verticale**. Nella pagina Ordini la tabella occupa quasi tutto lo schermo, quindi il dito ci finisce sempre sopra: Chrome aggancia il gesto a quel contenitore, che in verticale non ha niente da scorrere (o un pixel per arrotondamento), e la pagina resta ferma. Gli altri browser passano il gesto alla pagina. - **Perché solo lì:** è la tabella più larga, l'unica che sfora davvero lo schermo — infatti Benza la scorre in orizzontale. Dove il contenitore non è scrollabile Chrome non lo aggancia e la pagina scorre normalmente. - **Fix:** `.table-responsive { overflow-y: hidden; }` in `style.css`. Il contenitore scorre solo in orizzontale e il gesto verticale torna alla pagina. **Non era questa la causa del problema di Benza** (i dati dal suo telefono hanno poi indicato html/body, vedi la voce sopra): la modifica resta perché toglie comunque uno scroller verticale inutile sotto il dito, ed è innocua. **Nessun taglio di contenuto:** quei contenitori sono alti quanto la loro tabella (verificato `scrollHeight === clientHeight`). - **Verificato sul NAS** restringendo il contenitore a 380px per simulare un telefono: 461px di scroll orizzontale ancora disponibili e funzionanti, scroll verticale del contenitore a zero, niente contenuto tagliato. - **Insidia dei test:** in una finestra Chrome non visibile (`visibilityState: 'hidden'`) `window.scrollTo()` non muove la pagina e le transizioni CSS sono congelate. Sembrava il bug riprodotto sul desktop, ma succedeva anche su `clienti.php`, che il problema non ce l'ha: è l'ambiente di test, non la pagina. ### PERF — Anche la tendina "Affiliazione" cerca lato server (07/09/2026) Stesso trattamento dato alla tendina cliente del Nuovo Ordine, applicato alla scheda cliente: `clienti.js` scaricava tutta l'anagrafica per la select **Affiliazione**, cioè **9.212 `