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

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

Важливо

Команда для виклику CLI залежить від того, як ви встановили Odoo. У наведених нижче прикладах ми припускаємо, що ви запускаєте Odoo з джерела з файлом odoo-bin. Якщо ви встановили Odoo з дистрибутива або за допомогою Docker, ви потрібно адаптувати команду.

Run Odoo from sourceOdoo was installed from a distribution packageOdoo was installed with Docker

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

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

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

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

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

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

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

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

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

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

--addons-path <directories>

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

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

надайте альтернативний конфігураційний файл

-s, --save

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

--without-demo

вимикає завантаження демонстраційних даних для встановлених модулів через кому, використовуйте all для всіх модулів.

--test-enable

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

--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“

Ел. пошта

--email-from <address>

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

--smtp <server>

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

--smtp-port <port>

--smtp-ssl

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

--smtp-user <name>

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

--smtp-password <password>

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

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

Використовуйте ці параметри, щоб перекласти 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>

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

• xml: читати шаблон qweb безпосередньо з файлу xml замість бази даних. Після того, як шаблон буде змінено в базі даних, він не буде прочитаний з файлу xml до наступного оновлення/ініціалізації.

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

• qweb: перерва в оцінці шаблону qweb, коли вузол містить t-debug='debugger'

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

HTTP

--no-http

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

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

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

--http-interface <interface>

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

--http-port <port>

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

--longpolling-port <port>

Порт TCP для з’єднань із тривалим опитуванням у багатопроцесорному режимі або режимі gevent, за замовчуванням 8072. Не використовується в режимі за замовчуванням (потоковим).

--proxy-mode

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

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

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

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

За замовчуванням Odoo відображає всі журнали level info, за винятком журналів робочого процесу (лише warning), а вихід журналу надсилається до stdout. Доступні різні параметри для перенаправлення журналу в інші місця призначення та налаштування кількості вихідних даних журналу.

--logfile <file>

надсилає вихідні дані журналу у вказаний файл замість stdout. В Unix файлом можна керувати зовнішніми програмами ротації журналів і буде автоматично повторно відкрито після заміни

--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-request

увімкнути журнал DEBUG для запитів RPC, еквівалент --log-handler=odoo.http.rpc.request:DEBUG

--log-response

увімкнути журнал DEBUG для відповідей RPC, еквівалент --log-handler=odoo.http.rpc.response:DEBUG

--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>

Максимально дозволена кількість віртуальної пам’яті на одного воркера в байтах. Якщо ліміт перевищено, воркер завершується та перезапускається після завершення поточного запиту.

За замовчуванням використовується значення 2048MiB (2048*1024*1024B).

--limit-memory-hard <limit>

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

За замовчуванням використовується значення 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.

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

Більшість параметрів командного рядка також можна вказати за допомогою файлу конфігурації. Здебільшого вони використовують схожі назви з видаленим префіксом -, а інші - замінюються на _, наприклад. --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

Оболонка

Командний рядок Odoo також дозволяє запускати odoo як консольне середовище Python. Це забезпечує пряму взаємодію з orm та його функціями.

$ odoo_bin shell

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

Укажіть бажаний REPL для використання в режимі оболонки.

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 підтримує функції заповнення бази даних. Якщо цю функцію реалізовано на даній моделі, вона дозволяє автоматично генерувати дані про записи моделі для тестування ваших модулів у базах даних, що містять нетривіальну кількість записів.

$ odoo_bin populate

--models

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

--size (small|medium|large)

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

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

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

Cloc

Odoo Cloc - це інструмент для підрахунку кількості відповідних рядків, написаних на Python, Javascript або XML. Це можна використовувати як приблизну метрику для ціноутворення на підтримку додаткових модулів.

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

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

Обробити код усіх додаткових модулів, установлених у наданій базі даних, а також усіх дій сервера та обчислених полів, створених вручну в наданій базі даних.

Параметр --addons-path потрібен для вказівки шляху(ів) до папки модуля(ів).

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

$ odoo-bin cloc --addons-path=addons -d my_database

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

• З опцією --database

-p <path>, --path <path>

Обробити файли за вказаним шляхом.

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

$ odoo-bin cloc -p addons/account

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

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

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

• З опцією --path

--addons-path <directories>

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

Необхідний, якщо використовується параметр --database.

-c <directories>

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

$ odoo-bin cloc -c config.conf -d my_database

-v, --verbose

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

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

З опцією --database

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

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

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

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

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

• Сценарії міграції, визначені в папці migrations

• Файли 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
]

Шаблон **/* можна використовувати для ігнорування цілого модуля. Це може бути корисним для виключення модуля з витрат на технічне обслуговування.

Щоб отримати додаткові відомості про синтаксис шаблону, перегляньте glob.

З опцією --path

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

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

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

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

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

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

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

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

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

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

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