Odoo 20 amplia la modalità offline in modo che gli utenti possano creare, modificare, archiviare, riattivare e eliminare record senza una connessione attiva. Anche le ricerche eseguite in precedenza possono essere eseguite offline. Quando la connettività torna disponibile, le code di sincronizzazione gestiscono le modifiche, con un'interfaccia offline e strumenti di gestione per monitorare il processo. (Note di rilascio di Odoo 20; Odoo va offline) Questo sposta l'accesso offline da un fallback di sola visualizzazione a una modalità operativa che può modificare i dati aziendali. Le organizzazioni che valutano Odoo 20 dovrebbero esaminare come tali modifiche si comportano quando vengono sincronizzate, non solo se i record restano accessibili durante un'interruzione.
Odoo Nightly elenca Odoo 20 come release stabile e consigliata della Community Edition, datata settembre 2026 e supportata fino a Odoo 23. (nightly.odoo.com) Questo elenco è rilevante per la pianificazione della Community Edition, ma non stabilisce una copertura offline identica per ogni piattaforma, ambiente Enterprise o database personalizzato. La copertura va verificata rispetto alla distribuzione prevista.
Cosa è cambiato rispetto a Odoo 19
La modalità offline di Odoo 19 consente agli utenti di visualizzare i record aperti prima della perdita della connessione, ma non di modificarli offline. Odoo 20 aggiunge creazione, modifica, archiviazione, riattivazione ed eliminazione dei record. (Documentazione Odoo 19.0: Modalità offline generale; Note di rilascio di Odoo 20) Si tratta di un'estensione funzionale, non di una nuova etichetta per la cache precedente. In Odoo 19, gli utenti possono prepararsi alla disconnessione aprendo i record pertinenti, ma le operazioni che modificano tali record devono attendere la connettività. Odoo 20 supporta sia i nuovi record sia le modifiche a quelli esistenti mentre è offline. (Documentazione Odoo 19.0: Modalità offline generale; Note di rilascio di Odoo 20)
Le valutazioni delle versioni dovrebbero distinguere tra l'accesso alle informazioni memorizzate nella cache e la possibilità di completare e mettere in coda operazioni sui record. Un flusso di lavoro che richiede solo dati di riferimento ha esigenze diverse da uno che comporta inserimento dati, modifiche di stato o eliminazione. (Documentazione Odoo 19.0: Modalità offline generale; Note di rilascio di Odoo 20)
Operazioni offline confermate
Le azioni confermate di Odoo 20 coprono cinque fasi del ciclo di vita del record: creazione, modifica, archiviazione, riattivazione ed eliminazione. Anche le ricerche eseguite in precedenza sono disponibili offline. (Note di rilascio di Odoo 20) I test di accettazione dovrebbero includere almeno uno scenario per ogni azione e confermare che lo stato previsto del record appaia dopo la reconnessione e la sincronizzazione.
La sessione Experience di Odoo descrive un'interfaccia offline dedicata, code di sincronizzazione e strumenti per monitorare e gestire la sincronizzazione. (Odoo va offline) Queste funzioni dovrebbero essere incluse nella formazione degli utenti e nelle procedure operative. Gli utenti devono sapere dove compaiono gli elementi in coda, come identificare un elemento irrisolto e chi lo esamina. Il materiale fornito conferma che esistono strumenti di gestione, ma non definisce il loro flusso di lavoro completo o le autorizzazioni amministrative.
La copertura di caching e ricerca richiede verifiche
La documentazione di Odoo 19 descrive l'accesso offline in termini di record aperti prima della perdita della connettività. Odoo 20 conferma separatamente che le ricerche eseguite in precedenza possono essere eseguite offline. (Documentazione Odoo 19.0: Modalità offline generale; Note di rilascio di Odoo 20) Le fonti fornite non specificano quante informazioni correlate vengano conservate, per quanto tempo restino disponibili, se si applichino limiti di archiviazione o se ogni campo associato a un record memorizzato nella cache sia disponibile. Inoltre, non stabiliscono se ripetere una ricerca offline restituisca il set di risultati originale o solo i dati già memorizzati sul dispositivo.
Prima di approvare un flusso di lavoro offline, i team dovrebbero identificare le ricerche e i tipi di record necessari per ciascun ruolo. I test dovrebbero iniziare online eseguendo le ricerche pertinenti e aprendo i record richiesti. I tester possono quindi disconnettersi e ripetere le attività previste, compreso qualsiasi uso di allegati, record collegati e campi obbligatori. Questi sono punti di verifica, non limitazioni confermate, perché le informazioni di rilascio fornite non ne descrivono il comportamento. (Note di rilascio di Odoo 20)
La gestione dei conflitti richiede test
Le code di sincronizzazione e gli strumenti di gestione sono confermati, ma le fonti fornite non spiegano come Odoo 20 risolva le modifiche in conflitto sullo stesso record, gli errori di convalida dopo la riconnessione o le dipendenze tra le operazioni in coda. (Odoo Goes Offline) La presenza di una coda non stabilisce una politica di conflitto. Il suo comportamento dovrebbe essere dimostrato nella build e nella configurazione Odoo previste.
Un test di conflitto può prevedere che un utente modifichi un record offline mentre un altro modifica lo stesso record online. Dopo la riconnessione, il team dovrebbe esaminare i valori risultanti, lo stato della coda e la notifica all'utente. Test separati dovrebbero coprire una modifica offline a un record archiviato o eliminato altrove, e un record creato di recente che non supera una regola lato server. I test dovrebbero documentare se un aggiornamento ha la precedenza, se avviene una fusione o se è richiesto un intervento manuale. (Odoo Goes Offline)
Controlli di accesso e azioni distruttive
Poiché Odoo 20 include l'archiviazione offline, la riattivazione e l'eliminazione, la valutazione dovrebbe estendersi oltre la normale immissione dei dati. (Note di rilascio di Odoo 20) Le organizzazioni dovrebbero verificare se i diritti di accesso, le regole sui record e i requisiti di approvazione vengono applicati quando l'azione offline si verifica, durante la sincronizzazione o in entrambe le fasi. Le note di rilascio confermano le azioni disponibili, ma non spiegano come si comporti ciascun controllo di sicurezza senza connessione.
I test dovrebbero usare ruoli utente rappresentativi e non solo un account amministratore. Ogni ruolo dovrebbe tentare azioni consentite e vietate, sia connesso sia disconnesso. I tester dovrebbero quindi verificare se le modifiche in coda restano visibili, se i messaggi di rifiuto sono chiari e se i record archiviati, ripristinati o eliminati raggiungono lo stato finale previsto. I processi in cui l'eliminazione ha conseguenze significative dovrebbero avere una procedura offline documentata prima del rilascio. (Note di rilascio di Odoo 20; Odoo Goes Offline)
I moduli personalizzati richiedono test mirati
La funzionalità confermata riguarda le operazioni offline sui record di Odoo 20 e le funzionalità di sincronizzazione, ma le fonti fornite non indicano che ogni modulo personalizzato, modulo di terze parti, azione automatica o integrazione esterna sia compatibile con il lavoro offline. (Note di rilascio di Odoo 20; Odoo Goes Offline) Le implementazioni personalizzate dovrebbero quindi valutare il supporto modulo per modulo, invece di assumere che la modalità offline si applichi uniformemente all'intero database.
I test dovrebbero coprire campi personalizzati, comportamento onchange, valori obbligatori, valori calcolati e controlli lato server usati nei flussi di lavoro dell'organizzazione. Anche le integrazioni che normalmente reagiscono alla creazione o alla modifica di un record dovrebbero essere osservate dopo la sincronizzazione delle modifiche in coda. L'obiettivo non è presumere un guasto, ma determinare se ciascun elemento opera offline, attende la riconnessione, produce un elemento di coda rifiutato o richiede un processo diverso. (Note di rilascio di Odoo 20; Odoo Goes Offline)
Questioni da risolvere prima del rilascio
Odoo 20 offre un insieme più ampio e confermato di funzionalità offline rispetto a Odoo 19, supportato da un'interfaccia dedicata e da strumenti di sincronizzazione per il lavoro in coda. (Odoo 19.0 Docs: General Offline Mode; Note di rilascio di Odoo 20; Odoo Goes Offline) Prima di fare affidamento su tali funzionalità, un'organizzazione dovrebbe verificare quali applicazioni e tipi di record sono coperti, cosa gli utenti devono aprire o cercare prima della disconnessione, come vengono presentati i conflitti e chi monitora la sincronizzazione fallita o ritardata.
La decisione di rilascio dovrebbe inoltre registrare i dispositivi e gli ambienti di distribuzione supportati, il comportamento di archiviazione e conservazione, i risultati del controllo degli accessi, gli esiti dei moduli personalizzati e le procedure per l'eliminazione o altre modifiche rilevanti. Il materiale di rilascio fornito non risponde a queste domande di implementazione, ma esse determinano se le funzioni confermate siano adatte a un particolare flusso di lavoro offline. (Note di rilascio di Odoo 20; Odoo Goes Offline)
Per la pianificazione della Community Edition, l'elenco stable and recommended di Odoo Nightly fornisce lo stato della versione indicato, con supporto fino a Odoo 23. (nightly.odoo.com) L'approvazione operativa dovrebbe comunque dipendere dal test della build esatta, dei moduli, delle autorizzazioni e dei flussi di lavoro che gli utenti porteranno offline. Il cambiamento confermato è che Odoo 20 va oltre l'accesso in sola lettura di Odoo 19 ai record precedentemente aperti, consentendo la creazione e la modifica offline in coda. I test devono stabilire come tale funzionalità si comporti nella configurazione dell'organizzazione. (Documentazione Odoo 19.0: modalità offline generale; Note di rilascio Odoo 20; Odoo va offline)