Moduły OCA a Odoo 20: co działa, co poprawić, checklista
OCA sprawdza moduły pod Odoo 20; brak centralnej listy zgodności - partnerzy muszą samodzielnie testować instalacje, migracje i frontend.
Społeczność OCA sprawdza swoje repozytoria pod kątem Odoo 20. W organizacji OCA na GitHubie pojawił się wątek o testach instalacyjnych, ale publicznie dostępnych szczegółów jest niewiele. Nie wiadomo jeszcze, które moduły instalują się bez zmian, a które będą wymagały poprawek. Partner, który utrzymuje u klientów sporo modułów społecznościowych, nie powinien więc czekać na gotową listę zgodności.
Co wiadomo o stanie prac w OCA
Najważniejsza informacja jest mało efektowna: nie ma jednego, centralnego spisu niekompatybilności. Wyniki testów, zgłoszenia i poprawki trafiają do issue i pull requestów w poszczególnych repozytoriach, tam gdzie autorzy je przygotowali. W jednych repozytoriach problemy są już opisane, w innych na razie nic się nie dzieje. Brak wpisu nie oznacza, że moduł działa. Często znaczy tylko tyle, że nikt go jeszcze nie sprawdził.
Otwarte zostaje też pytanie, ile repozytoriów będzie gotowych w chwili, gdy klienci zaczną pytać o aktualizację. Na podstawie dostępnych dyskusji nie da się tego przewidzieć.
Co jest sprawdzane
Dostępne źródło podaje jedynie tytuł wątku o testach instalacyjnych. Nie opisuje, co dokładnie jest testowane, na jakich gałęziach ani czy prace obejmują coś więcej niż samą instalację modułów. Nie wiadomo, czy uruchamiane są testy jednostkowe i integracyjne ani czy ktoś sprawdza migracje danych.
Z tego wynika praktyczny wniosek: nawet jeśli moduł przejdzie test instalacyjny, nie należy zakładać, że zweryfikowano jego działanie na danych klienta. Do czasu, aż OCA doprecyzuje zakres testów, tę część pracy partner musi wykonać sam.
Gdzie szukać wyników
OCA zbiera informacje przez GitHub Discussions, issue i pull requesty. Globalne wątki dają ogólny obraz, ale konkrety pojawiają się w repozytoriach poszczególnych modułów, w zgłoszeniach dotyczących gałęzi 20.0. Tam najwcześniej widać pierwsze błędy i PR-y z poprawkami. Lepiej obserwować dokładnie te repozytoria, z których korzystają wdrożenia klientów, niż śledzić całą organizację.
Osobną kategorią są artykuły o nowościach w Odoo 20 publikowane przez firmy i blogi branżowe. Pomagają zorientować się, czego się spodziewać. Dopóki jednak zmiana nie jest widoczna w kodzie, traktujemy takie opisy jak zapowiedź, a nie podstawę do planowania prac.
Gdzie warto szukać problemów
Dostępne źródła nie zawierają zgłoszeń dotyczących ORM, migracji ani frontendu w Odoo 20. Poniższe trzy obszary to nie obserwacja z dyskusji OCA, tylko miejsca, które przy każdej zmianie wersji głównej warto sprawdzić w pierwszej kolejności. Odoo nie podało, jakie konkretnie zmiany w tych obszarach przynosi wersja 20.
API ORM
Nie wiadomo, czy w Odoo 20 zmieniły się sygnatury metod ORM, bo źródła tego nie opisują. Gdyby tak się stało, możliwe są dwa scenariusze. Albo moduł wywraca się już przy imporcie, albo działa do chwili, gdy użytkownik uruchomi akcję korzystającą ze zmienionej metody. Drugi przypadek byłby trudniejszy do wychwycenia, bo sam test instalacji mógłby go nie ujawnić. To przypuszczenie, a nie potwierdzony stan rzeczy.
Migracje danych
Skrypty pisane pod starsze wersje zakładają określoną strukturę modelu: nazwy pól, typy, mapowania wartości. Jeśli w Odoo 20 model przebudowano, skrypt może się wykonać bez błędu i zostawić w bazie złe rekordy. Taki błąd kosztuje najwięcej, bo wychodzi dopiero na danych produkcyjnych. Najbardziej narażone są moduły bez testów migracyjnych.
Frontend i assety
Moduły z własnymi widżetami JS i CSS to kolejny obszar do przejrzenia. Źródła nie mówią, czy w Odoo 20 zmienił się sposób rejestracji komponentów Owl albo deklarowania assetów, więc dziś nie da się ocenić skali ewentualnych prac. Moduły czysto backendowe, bez własnego JavaScriptu, ten obszar w ogóle nie dotyczy.
Co trzeba poprawić w kodzie
Źródła nie wymieniają PR-ów naprawczych pod Odoo 20, więc nie da się powiedzieć, które poprawki pojawiają się najczęściej. Poniżej zbieramy obszary, które warto przejrzeć niezależnie od tego.
Wywołania API
Pierwszy krok to przegląd użycia metod ORM i sprawdzenie, czy pasują do sygnatur w Odoo 20. Ostrzeżenia w logach bywają tu cenniejsze niż wyjątki. Pokazują miejsca, które na razie działają, ale już sygnalizują problem.
Przy okazji opłaca się usunąć kod oparty na wewnętrznych, nieudokumentowanych mechanizmach Odoo. Taki fragment przy kolejnej wersji znów będzie do poprawy.
Skrypty migracyjne
Bez testów nie da się tu niczego rozsądnie ocenić. Dla modeli, w których pola zmieniały się między wersjami, trzeba dopisać testy migracyjne albo uzupełnić istniejące. Osobno należy sprawdzić konwersje typów i wartości domyślne. Rozjazd w jednym polu potrafi długo przechodzić niezauważony, aż ktoś trafi na złą kwotę na fakturze.
Widoki i JavaScript
Najpierw trzeba ustalić, które pliki JS i CSS ładuje moduł, i sprawdzić, czy komponenty oraz szablony wymagają dostosowania do Owl. Potem przychodzi kolej na manifest. Ścieżki do assetów i sposób ich rejestracji to pierwsze miejsca do sprawdzenia po aktualizacji.
Checklista dla partnerów
Poniższa lista ma dać szybką mapę prac, zanim aktualizacja trafi na produkcję. Nie zastąpi testów z użytkownikami, ale pozwala wcześnie ocenić skalę problemu.
Test instalacji pojedynczego modułu
- Skopiować repozytorium modułu do odseparowanego środowiska testowego z Odoo 20.
- Zainstalować moduł i zapisać wszystkie wyjątki oraz istotne wpisy z logów.
- Porównać zależności i wersje bibliotek Pythona, na przykład przez
pip freeze, i zaktualizować te, które tego wymagają. - Wyszukać w kodzie miejsca związane z Owl i assetami:
grep -R "owl.Component" addons/ | head -n 20
grep -R "web.assets" addons/ | head -n 20
Te dwa polecenia to zgrubne sito. Pokazują, które moduły mają własny frontend, ale nie wychwycą każdego sposobu importowania komponentów. Pusty wynik nie zwalnia z ręcznego przejrzenia plików JavaScript w module.
CI i testy automatyczne
- Uruchomić istniejące testy jednostkowe i integracyjne, a brakujące dopisać.
- Sprawdzić, czy pipeline CI korzysta z obrazu i bazy Odoo 20 oraz z właściwych wersji zależności.
- Dodać test migracyjny według prostego scenariusza: baza z poprzedniej wersji, migracja, porównanie danych istotnych dla klienta.
Ostatni punkt wymaga najwięcej pracy i najłatwiej go odłożyć „na później”. Dlatego trzeba go zaplanować na samym początku.
Kolejność prac w zespole
Moduły dobrze jest uszeregować według tego, co zatrzyma firmę klienta, jeśli przestanie działać. Fakturacja, magazyn i POS idą na początek, raporty i dodatki kosmetyczne mogą poczekać.
Każdą zmianę należy opisać w changelogu repozytorium razem z testami regresyjnymi, bo to skraca code review po stronie maintainerów OCA. Jeśli błąd ma już otwarte issue albo PR z poprawką, lepiej dołączyć do tej pracy, niż utrzymywać własną łatkę, którą przy każdej aktualizacji trzeba będzie nakładać od nowa.
Źródła
Chcesz sprawdzić, jak Odoo sprawdziłoby się w Twojej firmie?
Skontaktuj się z nami - przeanalizujemy Twoje obecne procesy i pokażemy, od których 2–3 obszarów warto zacząć, żeby możliwie szybko zobaczyć efekt wdrożenia.