Advanced topics

This section covers advanced features of Odoo.sh related to containers, Git submodules, and scheduled actions.

Kontenery

Each build is isolated in its own container (Linux namespace container). The base is an Ubuntu-based system on which all of Odoo’s required dependencies, as well as common, useful packages, are installed.

If your project requires additional Python dependencies or more recent releases, you can define a requirements.txt file at the root of your branches that lists them. The platform will ensure these dependencies are installed in your containers.

Zobacz także

• For a concrete example, check out the Odoo Community requirements.txt file.

• PyPA requirements specifiers documentation

Informacja

The requirements.txt files of submodules are also taken into account. The platform looks for such files in the parent folder of each folder containing an Odoo module.

Struktura katalogów

As the containers are Ubuntu-based, their directory structure follows the Filesystem Hierarchy Standard.

Zobacz także

Ubuntu main directories documentation

The directories relevant to Odoo.sh are the following:

.
├── home
│    └── odoo
│         ├── backup.daily
│         ├── data
│         │    ├── filestore           Database attachments, as well as the files of binary fields
│         │    └── sessions            Visitors and users sessions
│         ├── logs
│         │    ├── install.log         Database installation logs
│         │    ├── odoo.log            Running server logs
│         │    ├── update.log          Database updates logs
│         │    └── pip.log             Python packages installation logs
│         └── src
│              ├── odoo                Odoo Community source code
│              │    └── odoo-bin       Odoo server executable
│              ├── enterprise          Odoo Enterprise source code
│              ├── themes              Odoo Themes source code
│              └── user                Your repository branch source code
└── usr
     ├── lib
     │    └── pythonX.XX
     │         └── dist-packages       Python X.XX standard libraries
     ├── local
     │    └── lib
     │         └── pythonX.XX
     │              └── dist-packages  Python X.XX third-party libraries
     └── usr
          └── bin
               └── pythonX.X           Python X.XX executable

Powłoka bazy danych

While accessing a container with the shell, you can access the database using the psql command.

odoo@odoo-master-1.odoo.sh:~$ psql
psql (16.9)
Type "help" for help.

odoo-master-1=>

Ostrzeżenie

Always use transactions (e.g., BEGIN (…) COMMIT / ROLLBACK) when an SQL statement leads to changes (e.g., UPDATE, DELETE, ALTER, etc.) , especially for your production database. The transaction mechanism is your safety net in case of a mistake. You simply have to rollback your changes to revert your database to its previous state.

Do not forget to commit or roll back transactions. Open transactions may lock records in your tables, and a running database may wait for them to be released, causing a server to hang indefinitely.

In addition, use your staging databases to test your statements first. It gives you an extra safety net.

Example

You forgot to set your WHERE condition. In such a case, you can rollback to revert the unwanted change:

odoo-master-1=> BEGIN;
BEGIN
odoo-master-1=> UPDATE res_users SET password = '***';
UPDATE 457
odoo-master-1=> ROLLBACK;
ROLLBACK

Then, rewrite the statement and commit the change:

odoo-master-1=> BEGIN;
BEGIN
odoo-master-1=> UPDATE res_users SET password = '***' WHERE id = 1;
UPDATE 1
odoo-master-1=> COMMIT;
COMMIT

Uruchom serwer Odoo

You can start an Odoo server instance from a container shell. You won’t be able to access it from the outside world with a web browser, but you can, for example:

• Skorzystaj z powłoki Odoo:

  odoo-bin shell
  >>> partner = env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1)
  >>> partner.name
  'ASUSTeK'
  >>> partner.name = 'Odoo'
  >>> env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1).name
  'Odoo'
  

• Zainstaluj moduł:

  odoo-bin -i sale --without-demo=all --stop-after-init
  

  Wskazówka

  • Argument --without-demo=all zapobiega wczytywaniu danych demonstracyjnych dla wszystkich modułów.

  • Argument --stop-after-init natychmiast wyłącza instancję serwera po zakończeniu operacji.

• Zaktualizuj moduł:

  odoo-bin -u sale --stop-after-init
  

• Uruchom testy dla modułu:

  odoo-bin -i sale --test-enable --log-level=test --stop-after-init
  

Zobacz także

Dokumentacja CLI

Aby znaleźć ścieżkę dodatków używaną przez Odoo.sh do uruchamiania serwera, poszukaj „odoo: addons paths” w logach (~/logs/odoo.log).

2025-02-19 10:51:39,267 4 INFO ? odoo: Odoo version 18.0
2025-02-19 10:51:39,268 4 INFO ? odoo: Using configuration file at /home/odoo/.config/odoo/odoo.conf
2025-02-19 10:51:39,268 4 INFO ? odoo: addons paths: ['/home/odoo/data/addons/18.0', '/home/odoo/src/user', '/home/odoo/src/enterprise', '/home/odoo/src/themes', '/home/odoo/src/odoo/addons', '/home/odoo/src/odoo/odoo/addons']

Ostrzeżenie

Operacje wykonywane na instancji serwera Odoo nie są izolowane; zmiany zostaną odzwierciedlone w bazie danych. Pamiętaj, aby zawsze przeprowadzać testy w bazach danych staging.

Debugowanie w Odoo.sh

Informacja

Debugowanie kompilacji (build) Odoo.sh niewiele różni się od debugowania innej aplikacji w Pythonie. Celem tej sekcji jest omówienie specyfiki i ograniczeń platformy Odoo.sh, przy założeniu, że użytkownik już wie, jak korzystać z debuggera.

Do debugowania kodu w Odoo.sh można użyć pdb, pudb lub ipdb. Ponieważ serwer działa poza powłoką, nie można uruchomić debuggera bezpośrednio z zaplecza Odoo, ponieważ wymaga on powłoki do działania.

pdb jest domyślnie zainstalowany w każdym kontenerze.

Wskazówka

Aby użyć pudb lub ipdb, należy je zainstalować w jeden z poniższych sposobów:

• na stałe, dodając pudb lub ipdb do pliku requirements.txt projektu, lub

• tymczasowo (tylko w bieżącej kompilacji), uruchamiając odpowiednie polecenie:

  pip install pudb --user
  

  pip install ipdb --user
  

1. Aby uruchomić debugger, dodaj to do kodu, który chcesz debugować:

   import sys
   if sys.__stdin__.isatty():
       import pdb; pdb.set_trace()
   

   Informacja

   Warunek sys.__stdin__.isatty() to obejście umożliwiające wykrycie, czy Odoo jest uruchamiane z poziomu powłoki.

2. Następnie zapisz plik i uruchom powłokę Odoo:

   odoo-bin shell
   

3. Użyj powłoki Odoo, aby uruchomić kod, który chcesz debugować.

   

Podmoduły

Submoduły Git pozwalają połączyć zewnętrzne repozytoria bezpośrednio z projektem bez kopiowania kodu, usprawniając wdrażanie dzięki klonowaniu zależności razem z głównym kodem projektu. Zapewniają precyzyjną kontrolę wersji dzięki wyborowi konkretnych gałęzi i przypinaniu określonych rewizji commitów do aktualizacji według własnego uznania.

W Odoo.sh platforma automatycznie wykrywa submoduły i dodaje je do ścieżki dodatków w celu instalacji bazy danych, pod warunkiem, że przy integracji prywatnych repozytoriów skonfigurujesz klucz wdrożenia w ustawieniach projektu i repozytorium.

Dodawanie podmodułu

With Odoo.shWith Git (advanced)

Informacja

Obecnie nie ma możliwości dodawania prywatnych repozytoriów za pomocą Odoo.sh. Można to jednak zrobić za pomocą Gita.

1. W widoku Gałęzie Twojego projektu Odoo.sh wybierz gałąź, do której chcesz dodać submoduł.

2. W prawym górnym rogu kliknij Submoduł, a następnie Uruchom na Odoo.sh.

3. W oknie dialogowym uzupełnij następujące pola:

   • Adres URL repozytorium: adres SSH repozytorium

     Wskazówka

     Na GitHubie kliknij Clone, wybierz SSH i skopiuj adres URL.

     

   • Gałąź: konkretna gałąź, która ma zostać użyta

   • Ścieżka: folder, do którego submoduł ma zostać dodany w Twojej gałęzi

Wskazówka

Podczas dodawania repozytorium zawierającego wiele modułów, możesz chcieć zignorować niektóre z nich, jeśli są instalowane automatycznie. Aby to zrobić, poprzedź folder submodułu znakiem . (np. .folder). Platforma zignoruje ten folder, a Ty możesz ręcznie wybrać moduły, tworząc linki symboliczne do nich z innego folderu.

Zaplanowane akcje

Na platformie Odoo.sh zaplanowane działania są zaimplementowane nieco inaczej niż na zwykłym serwerze Odoo i są uruchamiane na zasadzie najlepszych starań. Wynika to z faktu, że na tym samym serwerze może znajdować się wielu klientów, a każdemu z nich gwarantowany jest sprawiedliwy podział zasobów serwera. Dlatego nie można zagwarantować dokładnego czasu wykonania zaplanowanych działań.

Ważne

Nie należy oczekiwać, że jakiekolwiek zaplanowane działanie będzie uruchamiane częściej niż co pięć minut.

Ponieważ czas wykonywania zaplanowanych akcji jest ograniczony, zaleca się dopilnowanie, aby te akcje:

• Działały na małych partiach rekordów.

• Zatwierdzały swoją pracę po przetworzeniu każdej partii, tak aby w razie przerwania z powodu limitu czasu nie trzeba było zaczynać od nowa.

• Były idempotentne, tzn. nie mogą powodować efektów ubocznych, jeśli zostaną uruchomione częściej niż oczekiwano.

IP address change

Odoo.sh powiadamia administratorów projektu o zmianach adresu IP. Dodatkowo, gdy zmienia się adres IP instancji produkcyjnej, wysyłane jest żądanie HTTP GET do ścieżki /_odoo.sh/ip-change z nowym adresem IP dołączonym jako parametr zapytania (new), wraz z poprzednim adresem IP jako dodatkowym parametrem (old).

This mechanism allows custom actions to be triggered in response to the IP address change (e.g., sending an email, contacting a firewall API, configuring database objects, etc.)

Ze względów bezpieczeństwa ścieżka /_odoo.sh/ip-change jest dostępna wyłącznie wewnętrznie przez samą platformę i zwraca odpowiedź 403, jeśli zostanie do niej uzyskany dostęp w inny sposób.

Oto przykładowa pseudo-implementacja:

class IPChangeController(http.Controller):

    @http.route('/_odoo.sh/ip-change', auth='public')
    def ip_change(self, old=None, new=None):
        _logger.info("IP address changed from %s to %s", old, new)
        # Then perform whatever action is required for your use case, e.g., update an
        # ir.config_parameter, send an email, contact an external firewall service's API, ...
        return 'ok'