Odoo 20 extinde modul offline, astfel încât utilizatorii pot crea, edita, arhiva, dezarhiva și șterge înregistrări fără o conexiune activă. Căutările efectuate anterior pot fi, de asemenea, rulate offline. După revenirea conectivității, cozile de sincronizare gestionează modificările, iar o interfață offline și instrumente de administrare permit monitorizarea procesului. (Odoo 20 Release Notes; Odoo Goes Offline) Acest lucru mută accesul offline de la o soluție de rezervă pentru vizualizare la un mod de lucru care poate modifica datele de business. Organizațiile care evaluează Odoo 20 ar trebui să examineze modul în care aceste modificări se comportă la sincronizare, nu doar dacă înregistrările rămân accesibile în timpul unei întreruperi.
Odoo Nightly listează Odoo 20 ca o versiune Community Edition stabilă, recomandată, datată septembrie 2026 și suportată până la Odoo 23. (nightly.odoo.com) Această listare este relevantă pentru planificarea Community Edition, dar nu stabilește o acoperire offline identică pe fiecare platformă, în fiecare mediu Enterprise sau în fiecare bază de date personalizată. Acoperirea ar trebui verificată în raport cu implementarea dorită.
Ce s-a schimbat față de Odoo 19
Modul offline din Odoo 19 permite utilizatorilor să vadă înregistrările deschise înainte de pierderea conexiunii, dar nu să le modifice în timp ce sunt offline. Odoo 20 adaugă crearea, editarea, arhivarea, dezarhivarea și ștergerea înregistrărilor. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Aceasta este o extindere funcțională, nu o nouă etichetă pentru memoria cache anterioară. În Odoo 19, utilizatorii se pot pregăti pentru deconectare deschizând înregistrările relevante, dar lucrările care modifică acele înregistrări trebuie să aștepte conectivitatea. Odoo 20 acceptă atât înregistrări noi, cât și modificări ale celor existente, în timp ce este offline. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Evaluările versiunilor ar trebui să distingă între accesul la informațiile din cache și capacitatea de a finaliza și pune în coadă operațiuni asupra înregistrărilor. Un flux de lucru care necesită doar date de referință are cerințe diferite de unul care implică introducerea de date, schimbări de stare sau ștergere. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Operațiuni offline confirmate
Acțiunile confirmate din Odoo 20 acoperă cinci părți ale ciclului de viață al înregistrărilor: creare, editare, arhivare, dezarhivare și ștergere. Căutările executate anterior sunt, de asemenea, disponibile în timp ce sunteți offline. (Odoo 20 Release Notes) Testarea de acceptanță ar trebui să includă cel puțin un scenariu pentru fiecare acțiune și să confirme că starea așteptată a înregistrării apare după reconectare și sincronizare.
Sesiunea Experience a Odoo descrie o interfață offline dedicată, cozi de sincronizare și instrumente pentru monitorizarea și gestionarea sincronizării. (Odoo Goes Offline) Aceste funcții ar trebui incluse în instruirea utilizatorilor și în procedurile operaționale. Utilizatorii trebuie să știe unde apar elementele puse în coadă, cum să identifice un element nerezolvat și cine îl revizuiește. Materialul furnizat confirmă existența instrumentelor de administrare, dar nu definește fluxul lor complet de lucru sau permisiunile administrative.
Acoperirea cache-ului și a căutărilor necesită verificare
Documentația Odoo 19 descrie accesul offline în termeni de înregistrări deschise înainte de pierderea conectivității. Odoo 20 confirmă separat că căutările executate anterior pot fi rulate offline. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Sursele furnizate nu specifică cât de multe date asociate sunt păstrate, cât timp rămân disponibile, dacă se aplică limite de stocare sau dacă fiecare câmp asociat unei înregistrări din cache este disponibil. De asemenea, ele nu stabilesc dacă repetarea unei căutări offline returnează setul original de rezultate sau doar datele deja stocate pe dispozitiv.
Înainte de a aproba un flux de lucru offline, echipele ar trebui să identifice căutările și tipurile de înregistrări necesare fiecărui rol. Testarea ar trebui să înceapă online, prin executarea căutărilor relevante și deschiderea înregistrărilor necesare. Apoi, testerii se pot deconecta și pot repeta sarcinile dorite, inclusiv orice utilizare a atașamentelor, a înregistrărilor legate și a câmpurilor obligatorii. Acestea sunt puncte de verificare, nu limitări confirmate, deoarece informațiile furnizate despre lansare nu descriu comportamentul lor. (Odoo 20 Release Notes)
Gestionarea conflictelor necesită testare
Coada de sincronizare și instrumentele de administrare sunt confirmate, însă sursele furnizate nu explică modul în care Odoo 20 rezolvă modificările concurente ale aceluiași înregistrări, eșecurile de validare după reconectare sau dependențele dintre operațiunile puse în coadă. (Odoo Goes Offline) Prezența unei cozi nu stabilește o politică de conflict. Comportamentul acesteia ar trebui demonstrat în versiunea și configurația Odoo vizate.
Un test de conflict poate presupune ca un utilizator să modifice o înregistrare offline, în timp ce altul modifică aceeași înregistrare online. După reconectare, echipa ar trebui să examineze valorile rezultate, starea cozii și notificarea utilizatorului. Teste separate ar trebui să acopere o editare offline a unei înregistrări arhivate sau șterse în altă parte și o înregistrare creată recent care nu trece o regulă de server. Testarea ar trebui să documenteze dacă o actualizare are prioritate, dacă are loc o îmbinare sau dacă este necesară intervenția manuală. (Odoo Goes Offline)
Controale de acces și acțiuni distructive
Deoarece Odoo 20 include arhivare, dezarhivare și ștergere offline, evaluarea ar trebui să depășească introducerea obișnuită a datelor. (Odoo 20 Release Notes) Organizațiile ar trebui să verifice dacă drepturile de acces, regulile de înregistrare și cerințele de aprobare sunt aplicate atunci când acțiunea offline are loc, în timpul sincronizării sau în ambele etape. Notele de lansare confirmă acțiunile disponibile, dar nu explică modul în care se comportă fiecare control de securitate fără conexiune.
Testarea ar trebui să folosească roluri de utilizator reprezentative, nu doar un cont de administrator. Fiecare rol ar trebui să încerce acțiuni permise și interzise, atât conectat, cât și deconectat. Apoi, testerii ar trebui să verifice dacă modificările din coadă rămân vizibile, dacă mesajele de respingere sunt clare și dacă înregistrările arhivate, restaurate sau șterse ajung la starea finală dorită. Procesele în care ștergerea are consecințe semnificative ar trebui să aibă o procedură offline documentată înainte de implementare. (Odoo 20 Release Notes; Odoo Goes Offline)
Modulele personalizate necesită testare țintită
Funcționalitatea confirmată acoperă operațiunile offline asupra înregistrărilor și facilitățile de sincronizare din Odoo 20, însă sursele furnizate nu afirmă că fiecare modul personalizat, modul terț, acțiune automată sau integrare externă este compatibilă cu lucrul offline. (Odoo 20 Release Notes; Odoo Goes Offline) Implementările personalizate ar trebui, prin urmare, să evalueze suportul modul cu modul, în loc să presupună că modul offline se aplică uniform în întreaga bază de date.
Testarea ar trebui să acopere câmpurile personalizate, comportamentul onchange, valorile obligatorii, valorile calculate și verificările pe server utilizate în fluxurile de lucru ale organizației. Integrările care reacționează în mod normal la crearea sau editarea unei înregistrări ar trebui, de asemenea, observate după ce modificările din coadă se sincronizează. Scopul nu este să presupunem eșecul, ci să stabilim dacă fiecare element rulează offline, așteaptă reconectarea, produce un element respins în coadă sau necesită un proces diferit. (Odoo 20 Release Notes; Odoo Goes Offline)
Întrebări de clarificat înainte de lansare
Odoo 20 oferă un set confirmat mai amplu de capabilități offline decât Odoo 19, susținut de o interfață dedicată și de instrumente de sincronizare pentru lucrul pus în coadă. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes; Odoo Goes Offline) Înainte de a se baza pe aceste capabilități, o organizație ar trebui să verifice ce aplicații și tipuri de înregistrări sunt acoperite, ce trebuie să deschidă sau să caute utilizatorii înainte de deconectare, cum sunt prezentate conflictele și cine monitorizează sincronizarea eșuată sau întârziată.
Decizia de lansare ar trebui să înregistreze, de asemenea, dispozitivele și mediile de implementare suportate, comportamentul de stocare și păstrare, rezultatele privind controlul accesului, efectele modulelor personalizate și procedurile pentru ștergere sau alte modificări cu impact major. Materialele de lansare furnizate nu răspund la aceste întrebări de implementare, dar ele stabilesc dacă funcțiile confirmate se potrivesc unui anumit flux de lucru offline. (Odoo 20 Release Notes; Odoo Goes Offline)
Pentru planificarea Community Edition, lista stable și recommended din Odoo Nightly oferă starea versiunii menționată, cu suport până la Odoo 23. (nightly.odoo.com) Aprobarea operațională ar trebui să depindă în continuare de testarea exactă a build-ului, modulelor, permisiunilor și fluxurilor de lucru pe care utilizatorii le vor lua offline. Schimbarea confirmată este că Odoo 20 depășește accesul doar în citire din Odoo 19 la înregistrările deschise anterior, permițând crearea și modificarea offline, puse în coadă. Testarea trebuie să stabilească modul în care această capabilitate se comportă în configurația organizației. (Documentația Odoo 19.0: modul offline general; Note de lansare Odoo 20; Odoo trece offline)