Odoo 20 rozszerza tryb offline, tak aby użytkownicy mogli tworzyć, edytować, archiwizować, przywracać z archiwum i usuwać rekordy bez aktywnego połączenia. Można też uruchamiać wcześniej wykonane wyszukiwania offline. Po przywróceniu łączności kolejki synchronizacji obsługują zmiany, a interfejs offline i narzędzia administracyjne umożliwiają monitorowanie procesu. (Odoo 20 Release Notes; Odoo Goes Offline) To przesuwa dostęp offline z trybu awaryjnego do przeglądania do trybu roboczego, który może zmieniać dane biznesowe. Organizacje oceniające Odoo 20 powinny sprawdzić, jak te zmiany zachowują się po synchronizacji, a nie tylko to, czy rekordy pozostają dostępne podczas awarii.
Odoo Nightly podaje Odoo 20 jako stabilne, zalecane wydanie Community Edition, z datą September 2026 i wsparciem do Odoo 23. (nightly.odoo.com) To zestawienie ma znaczenie przy planowaniu Community Edition, ale nie potwierdza identycznego zakresu offline we wszystkich platformach, środowiskach Enterprise ani w zmodyfikowanych bazach danych. Zakres należy sprawdzić dla docelowego wdrożenia.
Co zmieniło się względem Odoo 19
Tryb offline w Odoo 19 pozwala użytkownikom przeglądać rekordy otwarte przed utratą połączenia, ale nie modyfikować ich offline. Odoo 20 dodaje tworzenie rekordów, edycję, archiwizację, przywracanie z archiwum i usuwanie. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) To jest rozszerzenie funkcjonalne, a nie nowa etykieta dla wcześniejszej pamięci podręcznej. W Odoo 19 użytkownicy mogą przygotować się na rozłączenie, otwierając odpowiednie rekordy, ale prace, które zmieniają te rekordy, muszą poczekać na łączność. Odoo 20 obsługuje zarówno nowe rekordy, jak i zmiany istniejących podczas pracy offline. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Oceny wersji powinny rozróżniać dostęp do danych z pamięci podręcznej od możliwości wykonywania i kolejkowania operacji na rekordach. Proces pracy wymagający wyłącznie danych referencyjnych ma inne wymagania niż taki, który obejmuje wprowadzanie danych, zmiany statusu lub usuwanie. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Potwierdzone operacje offline
Potwierdzone działania Odoo 20 obejmują pięć etapów cyklu życia rekordu: tworzenie, edycję, archiwizację, przywracanie z archiwum i usuwanie. Wcześniej wykonane wyszukiwania są również dostępne offline. (Odoo 20 Release Notes) Testy akceptacyjne powinny obejmować co najmniej jeden scenariusz dla każdego działania i potwierdzić, że oczekiwany stan rekordu pojawia się po ponownym połączeniu i synchronizacji.
Sesja Experience w Odoo opisuje dedykowany interfejs offline, kolejki synchronizacji oraz narzędzia do monitorowania i zarządzania synchronizacją. (Odoo Goes Offline) Te funkcje powinny zostać uwzględnione w szkoleniu użytkowników i procedurach operacyjnych. Użytkownicy muszą wiedzieć, gdzie pojawiają się elementy w kolejce, jak rozpoznać nierozwiązany element i kto go weryfikuje. Dostarczone materiały potwierdzają istnienie narzędzi administracyjnych, ale nie definiują pełnego przebiegu pracy ani uprawnień administracyjnych.
Należy zweryfikować zakres buforowania i wyszukiwania
Dokumentacja Odoo 19 opisuje dostęp offline w odniesieniu do rekordów otwartych przed utratą łączności. Odoo 20 osobno potwierdza, że wcześniej wykonane wyszukiwania mogą być uruchamiane offline. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Dostarczone źródła nie określają, ile powiązanych danych jest zachowywanych, jak długo pozostają dostępne, czy obowiązują limity pamięci ani czy każde pole powiązane z buforowanym rekordem jest dostępne. Nie ustalają też, czy ponowne uruchomienie wyszukiwania offline zwraca oryginalny zestaw wyników, czy tylko dane już zapisane na urządzeniu.
Przed zatwierdzeniem procesu offline zespoły powinny określić wyszukiwania i typy rekordów wymagane dla każdej roli. Testy powinny rozpocząć się online od uruchomienia odpowiednich wyszukiwań i otwarcia wymaganych rekordów. Następnie testerzy mogą rozłączyć się i powtórzyć zamierzone zadania, w tym użycie załączników, powiązanych rekordów i wymaganych pól. Są to punkty weryfikacji, a nie potwierdzone ograniczenia, ponieważ dostarczone informacje o wydaniu nie opisują ich zachowania. (Informacje o wydaniu Odoo 20)
Obsługa konfliktów wymaga testów
Kolejki synchronizacji i narzędzia do zarządzania są potwierdzone, ale dostarczone źródła nie wyjaśniają, jak Odoo 20 rozwiązuje sprzeczne zmiany tego samego rekordu, błędy walidacji po ponownym połączeniu ani zależności między operacjami w kolejce. (Odoo Goes Offline) Samo istnienie kolejki nie ustanawia polityki obsługi konfliktów. Jej działanie należy wykazać w docelowej wersji i konfiguracji Odoo.
Test konfliktu może polegać na tym, że jeden użytkownik zmienia rekord offline, a inny modyfikuje ten sam rekord online. Po ponownym połączeniu zespół powinien sprawdzić wynikowe wartości, stan kolejki oraz powiadomienia użytkownika. Osobne testy powinny objąć edycję offline rekordu zarchiwizowanego lub usuniętego w innym miejscu oraz nowo utworzony rekord, który nie przechodzi reguły po stronie serwera. Testy powinny dokumentować, czy aktualizacja ma pierwszeństwo, dochodzi do scalenia czy wymagane jest ręczne działanie. (Odoo Goes Offline)
Kontrola dostępu i działania destrukcyjne
Ponieważ Odoo 20 obejmuje archiwizowanie, cofanie archiwizacji i usuwanie offline, ocena powinna wykraczać poza zwykłe wprowadzanie danych. (Informacje o wydaniu Odoo 20) Organizacje powinny sprawdzić, czy uprawnienia dostępu, reguły rekordów i wymagania zatwierdzania są egzekwowane w momencie wykonania działania offline, podczas synchronizacji czy na obu etapach. Informacje o wydaniu potwierdzają dostępne działania, ale nie wyjaśniają, jak każde zabezpieczenie zachowuje się bez połączenia.
Testy powinny wykorzystywać reprezentatywne role użytkowników, a nie tylko konto administratora. Każda rola powinna próbować dozwolonych i niedozwolonych działań, będąc połączona i rozłączona. Testerzy powinni następnie sprawdzić, czy zmiany w kolejce pozostają widoczne, czy komunikaty o odrzuceniu są jasne oraz czy rekordy zarchiwizowane, przywrócone lub usunięte osiągają zamierzony stan końcowy. Procesy, w których usunięcie ma istotne konsekwencje, powinny mieć udokumentowaną procedurę offline przed wdrożeniem. (Informacje o wydaniu Odoo 20; Odoo Goes Offline)
Moduły niestandardowe wymagają testów ukierunkowanych
Potwierdzona funkcja obejmuje operacje offline na rekordach Odoo 20 oraz możliwości synchronizacji, ale dostarczone źródła nie stwierdzają, że każdy moduł niestandardowy, moduł zewnętrzny, automatyczna akcja ani integracja zewnętrzna jest zgodna z pracą offline. (Informacje o wydaniu Odoo 20; Odoo Goes Offline) Dostosowane wdrożenia powinny zatem oceniać obsługę moduł po module, zamiast zakładać, że tryb offline obowiązuje jednolicie w całej bazie danych.
Testy powinny obejmować pola niestandardowe, zachowanie onchange, wymagane wartości, wartości obliczane oraz kontrole po stronie serwera używane w przepływach pracy organizacji. Integracje, które zwykle reagują na tworzenie lub edycję rekordów, powinny być również obserwowane po zsynchronizowaniu zmian z kolejki. Celem nie jest zakładanie awarii, lecz ustalenie, czy każdy element działa offline, czeka na ponowne połączenie, generuje odrzucony element kolejki czy wymaga innego procesu. (Informacje o wydaniu Odoo 20; Odoo Goes Offline)
Pytania do rozstrzygnięcia przed wdrożeniem
Odoo 20 zapewnia szerszy, potwierdzony zestaw możliwości offline niż Odoo 19, wspierany przez dedykowany interfejs i narzędzia synchronizacji dla pracy w kolejce. (Dokumentacja Odoo 19.0: Ogólny tryb offline; Informacje o wydaniu Odoo 20; Odoo Goes Offline) Zanim organizacja zacznie polegać na tych możliwościach, powinna zweryfikować, które aplikacje i typy rekordów są objęte wsparciem, co użytkownicy muszą otworzyć lub wyszukać przed rozłączeniem, jak prezentowane są konflikty oraz kto monitoruje nieudaną lub opóźnioną synchronizację.
Decyzja o wdrożeniu powinna również uwzględniać obsługiwane urządzenia i środowiska wdrożeniowe, zachowanie dotyczące przechowywania i retencji, wyniki kontroli dostępu, rezultaty pracy modułów niestandardowych oraz procedury usuwania lub innych istotnych zmian. Dostarczone materiały o wydaniu nie odpowiadają na te pytania implementacyjne, ale to one decydują, czy potwierdzone funkcje pasują do konkretnego przepływu pracy offline. (Informacje o wydaniu Odoo 20; Odoo Goes Offline)
W przypadku planowania Community Edition lista stabilnej i zalecanej wersji Odoo Nightly podaje wskazany status wersji, z obsługą do Odoo 23. (nightly.odoo.com) Zatwierdzenie operacyjne powinno nadal zależeć od testów dokładnej kompilacji, modułów, uprawnień i przepływów pracy, które użytkownicy będą wykonywać offline. Potwierdzoną zmianą jest to, że Odoo 20 wykracza poza tylko do odczytu w Odoo 19 dla wcześniej otwartych rekordów, umożliwiając tworzenie i modyfikowanie offline w kolejce. Testy muszą ustalić, jak ta funkcja zachowuje się w konfiguracji organizacji. (Dokumentacja Odoo 19.0: Ogólny tryb offline; Informacje o wydaniu Odoo 20; Odoo przechodzi w tryb offline)