Publikacja modułu w Odoo App Store: reguły spisane i te, których uczysz się po 117 publikacjach

Odoo App Store to jedyny kanał, w którym moduł Odoo sprzedaje się bez handlowca: ktoś go wyszukuje, kupuje i instaluje. Publikacja jest bezpłatna i każdy może ją wykonać, mając repozytorium git i dobrze napisany manifest. Nigdzie nie jest opisane, dlaczego publikacja pojawia się po kilku dniach, dlaczego opis wyświetla się z błędami albo dlaczego moduł, który kompiluje się na Twoim komputerze, nie instaluje się w Odoo kupującego. Oto czego nauczyliśmy się, publikując 105 modułów i utrzymując je w Odoo 19, 18 i 17.

Reguły spisane: repozytorium, gałąź i manifest

Mechanizm jest prosty i warto go przestrzegać co do joty. Rejestrujesz repozytorium git na swoim koncie apps.odoo.com; App Store skanuje je i publikuje każdy znaleziony w nim moduł. Gałąź ma znaczenie: gałąź 19.0 zasila karty dla Odoo 19, 18.0 karty dla 18, a 17.0 karty dla 17. Ta sama nazwa techniczna w trzech gałęziach to jedna karta z trzema wersjami i właśnie tego chcesz: jeden adres URL, jedna strona z opiniami, trzy przyciski pobierania. Różne nazwy techniczne dla poszczególnych wersji to trzy karty, które dzielą między siebie odwiedziny.

Z manifestu App Store odczytuje i wyświetla:

• name, summary i category: tytuł karty, linię pod nim oraz miejsce w katalogu. Nazwa musi być unikalna w całym sklepie.
• version z prefiksem wersji Odoo (19.0.1.0.0): bez tego prefiksu karta nie wie, do jakiego Odoo należy.
• license: OPL-1 dla modułów płatnych, LGPL-3 lub AGPL-3 dla bezpłatnych. Płatny moduł na wolnej licencji to prezent, którego nie chciałeś dawać.
• price i currency: cena na karcie. Odoo zatrzymuje część każdej sprzedaży, a resztę Ci wypłaca; proporcja jest opublikowana w regulaminie App Store.
• images: lista zrzutów ekranu, zaczynając od banera widocznego w katalogu. Bez banera karta wyświetla się z szarą luką obok tych, które go mają.
• static/description/index.html: długi opis. HTML bez skryptów, obrazy względne wewnątrz modułu oraz, z doświadczenia, znaki ASCII: źle zakodowany znak diakrytyczny lub typograficzny cudzysłów mogą sprawić, że karta wyświetli zepsute symbole, które zobaczysz dopiero po publikacji.

Reguły, które nie są spisane

Ponowne skanowanie rządzi i nie wymusisz go plikiem zip

Po wykonaniu push karta nie zmienia się natychmiast: App Store ponownie skanuje repozytorium we własnym tempie, co może trwać godziny lub dni. Kusi, żeby ręcznie wgrać plik zip i „przyspieszyć”. Nie rób tego: wersja wgrana ręcznie i wersja zeskanowana z repozytorium współistnieją źle i kończysz z kartą, o której nie wiesz, skąd pochodzi. Stosujemy jedną zasadę: jedno źródło, czyli repozytorium, i cierpliwość. Jeśli chcesz, żeby skan zauważył zmianę, podnieś numer wersji w manifeście: zmiana treści przy tej samej wersji czasem nie zostaje wychwycona.

Kompilacja to nie instalacja

Skan nie instaluje modułu. To, że manifest jest poprawny, a kod importuje się bez błędów, nie oznacza, że moduł się zainstaluje. W Odoo 19 stało się to szczególnie zdradliwe: grupy zabezpieczeń zmieniły model (res.groups.privilege), ir.cron nie przyjmuje już pola numbercall, a widoki listy nazywają się list, nie tree. Moduł napisany dla wersji 17 przechodzi skan wersji 19 bez zastrzeżeń i nie instaluje się w Odoo kupującego. Opisujemy to w artykule dlaczego moduł Odoo 19 się kompiluje, ale nie instaluje.

Trzy wersje to trzy podobne moduły

Utrzymywanie tego samego modułu w wersjach 19, 18 i 17 to nie kopiowanie folderu do trzech gałęzi. Każda wersja ma swoje różnice w API, a jedyny sposób, by mieć pewność, że wszystkie trzy działają, to zainstalowanie ich w prawdziwym Odoo każdej wersji. My robimy to na Odoo.sh: jeden build na wersję, czysta instalacja, testy i dopiero wtedy push do gałęzi skanowanej przez App Store. A przy Odoo 20, które ukazało się we wrześniu 2026, proces jest ten sam, tyle że z jedną gałęzią więcej. Moduł przetestowany tylko w wersji, dla której go napisano, to moduł, który sprzeda się trzy razy i zawiedzie dwa razy.

Proces, którego się trzymamy, po kolei

1. Unikalna i ostateczna nazwa techniczna. Sprawdza się ją w App Store, zanim napiszesz pierwszą linię; zmiana później oznacza utratę karty i jej opinii.
2. Kompletny manifest od pierwszego commita: wersja z prefiksem, licencja, cena, kategoria, obrazy, dokładne zależności.
3. Czysta instalacja w prawdziwym Odoo.sh każdej wersji, która ma zostać opublikowana, z testami na zielono. Bez tego nie ma push.
4. Opis w ASCII z prawdziwymi zrzutami ekranu zainstalowanego modułu, a nie makietami. Kupujący porównuje to, co widzi na karcie, z tym, co instaluje.
5. Push do gałęzi wersji i czekanie na skan. Żadnych plików zip. Jeśli trzeba coś poprawić, podnosi się wersję i czeka ponownie.
6. Sprawdzenie opublikowanej karty we wszystkich trzech wersjach: baner, opis bez zepsutych symboli, cena, przycisk pobierania.

Czego publikacja nie zrobi za Ciebie

Publikacja to nie sprzedaż. Dobrze przygotowana karta pojawia się, gdy ktoś szuka dokładnie tego problemu, i to wszystko. O instalacji decyduje to, że moduł działa za pierwszym razem, że opis mówi, co robi, a czego nie robi, i że na pytania do wsparcia ktoś odpowiada. Dlatego każdy opublikowany moduł traktujemy jak produkt wraz z jego utrzymaniem, a nie jak wgrany plik. I dlatego, gdy firma programistyczna zamawia u nas konektor do swojego produktu, publikacja w App Store jest częścią pracy, a nie dodatkiem: to tam jej użytkownicy Odoo będą go szukać.

Najczęstsze pytania

Przydatne linki w FlexigoTech