Інтерфейс командного рядка (CLI)

CLI інтерфейс командного рядка пропонує кілька функцій, пов’язаних з Odoo. Ви можете використовувати його для запуску сервера, запуску Odoo як середовища консолі Python, розміщення модуля Odoo, заповнити базу даних або підрахувати кількість рядків коду.

Важливо

The command to use to call the CLI depends on how you installed Odoo. In the examples below, we assume that you are running Odoo from source with the odoo-bin file. If you installed Odoo from a distribution package or with Docker, you must adapt the command.

  1. Перейдіть до кореня каталогу, куди ви завантажили вихідні файли Odoo Community.

  2. Запустити всі команди CLI за допомогою ./odoo-bin

Help & version

-h, --help

shows help text with all available options

--version

shows Odoo version e.g. «Odoo Server 17.0»

Порада

You can enable auto-completion in your shell by running

echo "complete -W '`./odoo-bin --help | \
  sed -e 's/[^a-z_-]\(-\+[a-z0-9_-]\+\)/\n\1\n/' | \
  grep -- '^-' | sort | uniq | tr '\n' ' '`' odoo-bin" >> ~/.bash_completion

Запустити сервер

-d <database>, --database <database>

бази даних, які використовуються під час встановлення або оновлення модулів. Надання списку, розділеного комами, обмежує доступ до баз даних, наданих у списку.

Для розширених параметрів бази даних подивіться нижче.

-i <modules>, --init <modules>

розділений комами список модулів для встановлення перед запуском сервера (потрібно -d).

-u <modules>, --update <modules>

comma-separated list of modules to update before running the server. Use all for all modules. (requires -d).

--addons-path <directories>

розділений комами список каталогів, у яких зберігаються модулі. Ці каталоги скануються на наявність модулів.

--upgrade-path <upgrade_path>

specify an additional upgrade path.

--load <modules>

list of server-wide modules to load. Those modules are supposed to provide features not necessarily tied to a particular database. This is in contrast to modules that are always bound to a specific database when they are installed (i.e. the majority of Odoo addons). Default is base,web.

-c <config>, --config <config>

path to an alternate configuration file. If not defined, Odoo checks ODOO_RC environmental variable and default location $HOME/.odoorc. See configuration file section below.

-D <data-dir-path>, --data-dir <data-dir-path>

directory path where to store Odoo data (eg. filestore, sessions). If not specified, Odoo will fallback to a predefined path. On Unix systems its one defined in $XDG_DATA_HOME environmental variable or ~/.local/share/Odoo or /var/lib/Odoo.

-s, --save

зберігає конфігурацію сервера в поточному файлі конфігурації ($HOME/.odoorc за замовчуванням, і його можна змінити за допомогою -c).

--without-demo

disables demo data loading for modules installed comma-separated, use all for all modules. Requires -d and -i.

--pidfile=<pidfile>

path to a file where the server pid will be stored

--stop-after-init

stops the server after its initialization.

--geoip-city-db <path>

Absolute path to the GeoIP City database file.

--geoip-country-db <path>

Absolute path to the GeoIP Country database file.

Testing Configuration

--test-enable

запускає тести після встановлення модуля

--test-file <file>

runs a python test file

--test-tags [-][tag][/module][:class][.method]

Розділений комами список специфікацій для фільтрації тестів для виконання. Увімкнути модульні тести, якщо встановлено.

Приклад: --test-tags :TestClass.test_func,/test_module,external

  • - визначає, чи ми хочемо включити або виключити тести, що відповідають цій специфікації.

  • Тег відповідатиме тегам, доданим до класу з декоратором tagged() (усі тестові класи мають теги standard і at_install, поки явно видалено, дивіться документацію декоратора).

  • * відповідатиме всім тегам.

  • Якщо тег опущено в режимі включення, його значенням є standard.

  • Якщо тег опущено в режимі виключення, його значенням є *.

  • Модуль, клас і метод відповідно відповідатимуть назві модуля, назві тестового класу та назві тестового методу.

Фільтрація та виконання тестів відбувається двічі: відразу після кожного встановлення/оновлення модуля та в кінці завантаження модулів. На кожному етапі тести фільтруються за специфікаціями --test-tags і додатково за динамічними специфікаціями at_install і post_install відповідно.

--screenshots

Укажіть каталог, куди записувати знімки екрана, якщо тест HttpCase.browser_js не вдається. За замовчуванням /tmp/odoo_tests/db_name/screenshots

--screencasts

Увімкніть скрінкасти та вкажіть каталог для запису файлів скрінкастів. Для кодування кадрів у відеофайл необхідно встановити утиліту ffmpeg. Інакше кадри будуть збережені замість відеофайлу.

База даних

-r <user>, --db_user <user>

ім’я користувача бази даних, яке використовується для підключення до PostgreSQL.

-w <password>, --db_password <password>

пароль бази даних, якщо використовується автентифікація пароля.

--db_host <hostname>

хост для сервера бази даних

  • localhost у Windows

  • В іншому випадку сокет UNIX

--db_port <port>

порт, який прослуховує база даних, за замовчуванням 5432

--db-filter <filter>

приховує бази даних, які не відповідають <filter>. Фільтр є регулярним виразом із такими доповненнями:

  • %h замінюється повною назвою хоста, на якому зроблено запит.

  • %d замінюється субдоменом, на який зроблено запит, за винятком www (тому домен odoo.com і www.odoo.com відповідають базі даних odoo).

    Ці операції чутливі до регістру. Додайте опцію (?i), щоб відповідати всім базам даних (таким чином домен odoo.com, використовуючи (?i)%d, збігається з базою даних Odoo).

Починаючи з версії 11, також можна обмежити доступ до певної бази даних прослуховування, використовуючи параметр –database і вказуючи список баз даних, розділених комами

При поєднанні двох параметрів db-filter замінює список баз даних, розділених комами, для обмеження списку баз даних, тоді як список, розділений комами, використовується для виконання запитаних операцій, як-от оновлення модулів.

$ odoo-bin --db-filter ^11.*$

Обмежити доступ до баз даних, назва яких починається з 11

$ odoo-bin --database 11firstdatabase,11seconddatabase

Обмежити доступ лише до двох баз даних, 11firstdatabase та 11seconddatabase

$ odoo-bin --database 11firstdatabase,11seconddatabase -u base

Обмежте доступ лише до двох баз даних, 11firstdatabase і 11seconddatabase, і оновіть базовий модуль в одній базі даних: 11firstdatabase. Якщо база даних 11seconddatabase не існує, база даних створюється та встановлюються базові модулі

$ odoo-bin --db-filter ^11.*$ --database 11firstdatabase,11seconddatabase -u base

Обмежте доступ до баз даних, назва яких починається з 11, і оновіть базовий модуль для однієї бази даних: 11firstdatabase. Якщо база даних 11seconddatabase не існує, база даних створюється та встановлюються базові модулі

--db-template <template>

під час створення нових баз даних з екранів керування базами даних використовуйте вказану шаблон бази даних. За замовчуванням template0.

--pg_path </path/to/postgresql/binaries>

Шлях до двійкових файлів PostgreSQL, які використовуються менеджером баз даних для дампу та відновлення баз даних. Ви повинні вказати цей параметр, лише якщо ці двійкові файли розташовано в нестандартному каталозі.

--no-database-list

Пригнічує можливість переліку баз даних, доступних у системі

--db_sslmode

Контролюйте безпеку SSL підключення між Odoo і PostgreSQL. Значення має бути одним із таких: „disable“, „allow“, „prefer“, „require“, „verify-ca“ або „verify-full“. Значення за умовчанням - „prefer“

--unaccent

Try to enable the unaccent extension when creating new databases

Ел. пошта

--email-from <address>

Адреса ел. пошти використовується як <FROM>, коли Odoo потрібно надсилати листи

--from-filter <address or domain>

Define which email address the SMTP configuration will apply to. The field can be a domain name or an entire email address, or it can remain empty. If the sender’s email address does not match this set filter, then the email will be encapsulated using a combination of the two system parameters: mail.default.from and mail.catchall.domain. For example, «Admin» <admin@example.com> => «Admin» <notifications@mycompany.com>.

--smtp <server>

Адреса SMTP-сервера, до якого потрібно підключитися для надсилання пошти

--smtp-port <port>
--smtp-ssl

Якщо встановлено, odoo має використовувати з’єднання SMTP SSL/STARTSSL

--smtp-user <name>

Ім’я користувача для підключення до SMTP-сервера

--smtp-password <password>

Пароль для підключення до SMTP-сервера

--smtp-ssl-certificate-filename <path/to/cert.pem>

An SSL certificate is to be used for authentication. If set, then smtp-ssl-private-key is required.

--smtp-ssl-private-key-filename <path/to/key.pem>

An SSL private key is used for authentication. If set, then smtp-ssl-certificate is required.

Інтернаціоналізація

Використовуйте ці параметри, щоб перекласти Odoo іншою мовою. Див. розділ i18n посібника користувача. Опція „-d“ є обов’язковою. Параметр „-l“ є обов’язковим у разі імпорту

--load-language <languages>

вказує мови (розділені комами) для перекладів, які потрібно завантажити

-l, --language <language>

вкажіть мову файлу перекладу. Використовуйте його з –i18n-export або –i18n-import

--i18n-export <filename>

експортувати всі пропозиції для перекладу у файл CSV, файл PO або архів TGZ і вийти.

--i18n-import <filename>

імпортуйте файл CSV або PO з перекладами та вийдіть. Потрібна опція „-l“.

--i18n-overwrite

перезаписує існуючі терміни перекладу під час оновлення модуля або імпортування файлу CSV або PO.

--modules

вказати модулі для експорту. Використовуйте в поєднанні з –i18n-export

Розширені налаштування

Особливості розробника

--dev <feature,feature,...,feature>

comma-separated list of features. For development purposes only. Do not use it in production. Possible features are:

  • all: усі наведені нижче функції активовані

  • xml: read QWeb template from xml file directly instead of database. Once a template has been modified in database, it will be not be read from the xml file until the next update/init. Particularly, templates are not translated on using this option.

  • reload: перезавантажте сервер, коли оновлено файл python (може не бути виявлено залежно від використовуваного текстового редактора)

  • qweb: break in the evaluation of QWeb template when a node contains t-debug='debugger'

  • (i)p(u)db: запускати вибраний налагоджувач python у коді, коли виникає неочікувана помилка перед реєстрацією та поверненням помилки.

  • werkzeug: display the full traceback on the frontend page in case of exception

HTTP

--no-http

не запускайте HTTP або довге опитування робочих процесів (все одно можуть запускатися cron воркери)

Попередження

не має ефекту, якщо встановлено --test-enable, оскільки тести потребують доступного HTTP-сервера

--http-interface <interface>

TCP/IP-адреса, яку прослуховує HTTP-сервер, за замовчуванням 0.0.0.0 (усі адреси)

-p <port>
--http-port <port>

Порт, який прослуховує HTTP-сервер, за замовчуванням 8069.

--gevent-port <port>

TCP port for websocket connections in multiprocessing or gevent mode, defaults to 8072. Not used in default (threaded) mode.

--proxy-mode

дозволяє використовувати заголовки X-Forwarded-* через підтримку проксі Werkzeug.

It ignores all X-Forwarded-* headers in case X-Forwarded-Host is missing from the request.

It always gets the real IP from the last entry of the X-Forwarded-For chain. Configure your web server accordingly using directives such as nginx’s set_real_ip_from in case there are other trusted proxies along the chain that must be ignored.

X-Forwarded-Proto and X-Forwarded-Host are used to update the request root URL, which in turn is used to update the web.base.url system parameter upon a successful admin authentication. This system parameter is used to generate all links for the current database; see Веб-адреса бази даних бази даних.

Попередження

режим проксі не можна вмикати поза сценарієм зворотного проксі

--x-sendfile

delegates serving attachments files to the static web server and sets both X-Sendfile (apache) and X-Accel-* (nginx) http headers on stream responses. See Обслуговування статичних файлів і вкладень for web server configuration.

Ведення журналу

By default, Odoo displays all logging of level INFO, WARNING and ERROR. All logs independently of the level are output on stderr. Various options are available to redirect logging to other destinations and to customize the verbosity.

--logfile <file>

sends logging output to the specified file instead of stderr. On Unix, the file can be managed by external log rotation programs and will automatically be reopened when replaced

--syslog

реєструє системний журнал подій: syslog на unices і журнал подій на Windows.

Жоден не налаштовується

--log-db <dbname>

реєструє модель ir.logging (таблиця ir_logging) зазначеної бази даних. База даних може бути назвою бази даних у «current» PostgreSQL або URI PostgreSQL, наприклад. агрегація журналів.

--log-handler <handler-spec>

LOGGER:LEVEL, вмикає LOGGER на вказаному LEVEL, напр. odoo.models:DEBUG увімкне всі повідомлення журналу на рівні DEBUG або вище в моделях.

  • Двокрапка : є обов’язковою

  • Логер можна не використовувати, щоб налаштувати кореневий (за замовчуванням) обробник

  • Якщо рівень опущено, реєстратор встановлюється на INFO

Опцію можна повторити, щоб налаштувати кілька реєстраторів, наприклад.

$ odoo-bin --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler odoo.fields:WARNING
--log-web

вмикає журнал НАЛАШТУВАННЯ HTTP-запитів і відповідей, еквівалент --log-handler=odoo.http:DEBUG

--log-sql

вмикає журнал НАЛАШТУВАННЯ запитів SQL, еквівалент --log-handler=odoo.sql_db:DEBUG

--log-level <level>

Ярлик для зручнішого встановлення попередньо визначених рівнів на певних реєстраторах. «справжні» рівні (critical, error, warn, debug) встановлюються в реєстраторах odoo і werkzeug (за винятком debug, яке встановлено лише на odoo).

Odoo також надає псевдорівні налагодження, які застосовуються до різних наборів реєстраторів:

debug_sql

встановлює реєстратор SQL на debug

еквівалент --log-sql

debug_rpc

встановлює odoo і реєстратори запитів HTTP на debug

еквівалент --log-level debug --log-request

debug_rpc_answer

встановлює odoo і реєстратори запитів і відповідей HTTP на debug

еквівалент --log-level debug --log-request --log-response

Примітка

У разі конфлікту між --log-level і --log-handler використовується останній

Багатопроцесорність

--workers <count>

якщо count не дорівнює 0 (за замовчуванням), вмикає багатопроцесорність і встановлює вказану кількість воркерів HTTP (підпроцеси, що обробляють запити HTTP і RPC).

Примітка

багатопроцесорний режим доступний лише в системах на основі Unix

Кілька варіантів дозволяють обмежити та переробити воркерів:

--limit-request <limit>

Кількість запитів, які воркер обробить перед повторним використанням і перезапуском.

За замовчуванням 8196.

--limit-memory-soft <limit>

Maximum allowed virtual memory per worker in bytes. If the limit is exceeded, the worker is killed and recycled at the end of the current request.

Defaults to 2048MiB (2048*1024*1024B).

--limit-memory-hard <limit>

Hard limit on virtual memory in bytes, any worker exceeding the limit will be immediately killed without waiting for the end of the current request processing.

Defaults to 2560MiB (2560*1024*1024B).

--limit-time-cpu <limit>

Запобігає використанню воркером більше ніж <limit> секунд процесора для кожного запиту. Якщо ліміт перевищено, воркер знищується.

За замовчуванням 60.

--limit-time-real <limit>

Запобігає обробці запиту воркером довше <limit> секунд. Якщо ліміт перевищено, воркер знищується.

Відрізняється від --limit-time-cpu тим, що це обмеження «wall time», включаючи, напр. SQL запити.

За замовчуванням 120.

--max-cron-threads <count>

кількість воркерів, призначених для завдань cron. За замовчуванням 2. Воркери є потоки в багатопоточному режимі та процеси в багатопроцесорному режимі.

Для багатопроцесорного режиму це на додаток до процесів воркера HTTP.

--limit-time-worker-cron <limit>

Soft limit on how long a cron thread/worker is allowed to live before is is restarted, in seconds.

Set to 0 to disable.

Defaults to 0.

Файл конфігурації

Більшість параметрів командного рядка також можна вказати за допомогою файлу конфігурації. Здебільшого вони використовують схожі назви з видаленим префіксом -, а інші - замінюються на _, наприклад. --db-template стає db_template.

Деякі конверсії не відповідають шаблону:

  • --db-filter стає dbfilter

  • --no-http відповідає логічному значенню http_enable

  • попередні налаштування журналювання (усі параметри, що починаються з --log-, крім --log-handler і --log-db) просто додайте вміст до log_handler, використовуйте безпосередньо у файлі конфігурації

  • --smtp зберігається як smtp_server

  • --database зберігається як db_name

  • --i18n-import та --i18n-export взагалі недоступні з конфігураційних файлів

Типовим файлом конфігурації є $HOME/.odoorc, який можна змінити за допомогою --config. Якщо вказати --save, поточний стан конфігурації буде збережено у цьому файлі. Елементи конфігурації, що стосуються командного рядка, необхідно вказати в розділі [options].

Ось зразок файлу:

[options]
db_user=odoo
dbfilter=odoo

Оболонка

The Odoo command line also allows launching Odoo as a Python console environment, enabling direct interaction with the orm and its functionalities.

$ odoo-bin shell

Example

Adding an exclamation mark to all contacts“ names:

In [1]: records = env["res.partner"].search([])

In [2]: records
Out[2]: res.partner(14, 26, 33, 21, 10)

In [3]: for partner in records:
   ...:     partner.name = "%s !" % partner.name
   ...:

In [4]: env.cr.commit()

Важливо

By default, the shell is running in transaction mode. This means that any change made to the database is rolled back when exiting the shell. To commit changes, use env.cr.commit().

--shell-interface (ipython|ptpython|bpython|python)

Specify a preferred REPL to use in shell mode. This shell is started with the env variable already initialized to be able to access the ORM and other Odoo modules.

Перегляньте також

Середовище

Scaffolding

Scaffolding - це автоматизоване створення скелетної структури для спрощення завантаження (нових модулів, у випадку Odoo). Незважаючи на те, що це не обов’язково, це дозволяє уникнути втоми, пов’язаної зі встановленням основних структур і пошуком усіх початкових вимог.

Scaffolding доступний за допомогою підкоманди odoo-bin scaffold.

$ odoo-bin scaffold my_module /addons/
name (required)

назва модуля, який потрібно створити, може змінюватися різними способами для створення програмних назв (наприклад, назва каталогу модуля, назва моделей, …)

destination (default=current directory)

каталог, у якому буде створено новий модуль, за замовчуванням є поточним каталогом

-t <template>

каталог шаблону, файли передаються через jinja2, а потім копіюються в каталог destination

Це створить модуль my_module у каталозі /addons/.

Заповнення бази даних

Odoo CLI supports database population features. If the feature is implemented on a given model, it allows automatic data generation of the model’s records to test your modules in databases containing non-trivial amounts of records.

$ odoo-bin populate
--models

список моделей, для яких необхідно заповнити базу даних

--size (small|medium|large)

розмір популяції, фактична кількість записів залежить від атрибута _populate_sizes моделі. Згенерований вміст записів визначається методом _populate_factories() даної моделі (див. папку populate модулів для отримання додаткової інформації).

Перегляньте також

Заповнення бази даних

Cloc

Odoo Cloc is a tool to count the number of relevant lines written in Python, Javascript, CSS, SCSS, or XML. This can be used as a rough metric for pricing maintenance of extra modules.

Параметри командного рядка

-d <database>, --database <database>
Обробити код усіх додаткових модулів, установлених у наданій базі даних, а також усіх дій сервера та обчислених полів, створених вручну в наданій базі даних.
Параметр --addons-path потрібен для вказівки шляху(ів) до папки модуля(ів).
У поєднанні з --path підрахунок буде сумою результатів обох варіантів (з можливими перекриттями). Принаймні один із цих двох параметрів потрібен, щоб указати, який код обробляти.
$ odoo-bin cloc --addons-path=addons -d my_database

Перегляньте також

-p <path>, --path <path>
Обробити файли за вказаним шляхом.
У поєднанні з --database підрахунок буде сумою результатів обох варіантів (з можливими перекриттями). Принаймні один із цих двох параметрів потрібен, щоб указати, який код обробляти.
$ odoo-bin cloc -p addons/account

Можна надати кілька шляхів, повторивши опцію.

$ odoo-bin cloc -p addons/account -p addons/sale

Перегляньте також

--addons-path <directories>
Список розділених комами каталогів, у яких зберігаються модулі. Ці каталоги скануються на наявність модулів.
Необхідний, якщо використовується параметр --database.
-c <directories>

Укажіть файл конфігурації для використання замість параметра --addons-path.

$ odoo-bin cloc -c config.conf -d my_database
-v, --verbose

Показати деталі рядків, підрахованих для кожного файлу.

Оброблені файли

З опцією --database

Odoo Cloc counts the lines in each file of extra installed modules in a given database. In addition, it counts the Python lines of server actions and custom computed fields that have been directly created in the database or imported. Finally, it counts the lines of code of Javascript, CSS, and SCSS files, and of QWeb views from imported modules.

Деякі файли за замовчуванням виключаються з підрахунку:

  • Маніфест (__manifest__.py або __openerp__.py)

  • Вміст папки static/lib

  • Тести, визначені в папці tests і static/tests

  • The migrations scripts defined in the folder migrations and upgrades

  • Файли XML, оголошені в розділах demo або demo_xml маніфесту

Для особливих випадків для кожного модуля можна визначити список файлів, які Odoo Cloc має ігнорувати. Це визначається записом cloc_exclude маніфесту:

"cloc_exclude": [
    "lib/common.py", # exclude a single file
    "data/*.xml",    # exclude all XML files in a specific folder
    "example/**/*",  # exclude all files in a folder hierarchy recursively
    "**/*.scss",     # exclude all scss file from the module
]
Шаблон **/* можна використовувати для ігнорування цілого модуля. Це може бути корисним для виключення модуля з витрат на технічне обслуговування.
Щоб отримати додаткові відомості про синтаксис шаблону, перегляньте glob.

З опцією --path

Цей метод працює так само, як і з параметром –database, якщо файл маніфесту присутній у вказаній папці. В іншому випадку підраховуються всі файли.

Виявлення додаткових модулів

Щоб відрізнити стандартні та додаткові модулі, Odoo Cloc використовує таку евристику: модулі, які розташовані (справжній шлях до файлової системи після переходу за символічними посиланнями) у тому самому батьківському каталозі, що й base, web або ` Стандартні модулі web_enterprise` вважаються стандартними. Інші модулі розглядаються як додаткові модулі.

Обробка помилок

Деякі файли не можуть бути підраховані Odoo Cloc. Ці файли повідомляються в кінці виведення.

Перевищено максимальний розмір файлу

Odoo Cloc відхиляє будь-який файл, розмір якого перевищує 25 МБ. Зазвичай вихідні файли мають розмір менше 1 МБ. Якщо файл відхилено, це може бути:

  • Згенерований файл XML, який містить багато даних. Його слід виключити в маніфесті.

  • Бібліотека JavaScript, яку слід розмістити в папці static/lib.

Синтаксична помилка

Odoo Cloc не може підрахувати рядки коду файлу Python із проблемою синтаксису. Якщо додатковий модуль містить такі файли, їх слід виправити, щоб модуль міг завантажитися. Якщо модуль працює, незважаючи на наявність цих файлів, вони, ймовірно, не завантажені, тому їх слід видалити з модуля або принаймні виключити з маніфесту за допомогою cloc_exclude.

TSConfig Generator

When working on javascript, there are ways to help your editor providing you with powerful auto-completion. One of those ways is the use of a tsconfig.json file. Originally meant for typescript, editors can use its information with plain javascript also. With this config file, you will now have full auto-completion across modules.

The command to generate this files takes as many unnamed arguments as you need. Those are relative paths to your addon directories. In the example below, we move up one folder to save the tsconfig file in the folder containing community and enterprise.

$ community/odoo-bin tsconfig --addons-path community/addons,community/odoo/addons,enterprise > tsconfig.json