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

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

Важливо

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

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

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

Версія

-h, --help

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

Якщо команда не використовується, вона діятиме як команда help нижче.

--version

показує версію Odoo, наприклад, «Odoo Server 17.0»

Порада

Ви можете ввімкнути автозаповнення у вашій оболонці, виконавши команду

COMMANDS=$(odoo-bin --help | sed -e "s/^    \([^ ]\+\).*$/ \1/gp;d" | xargs)
echo "complete -W '$COMMANDS' odoo-bin" >> ~/.bash_completion

help - Показати доступні команди

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

У нього немає варіантів.

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

Ця команда використовується за замовчуванням: ви можете її пропустити, і вона все одно буде обрана.

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

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

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

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

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

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

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

--addons-path <directories>

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

--upgrade-path <upgrade_path>

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

--pre-upgrade-scripts <pre_upgrade_scripts>

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

--load <modules>

cписок модулів для завантаження на рівні сервера. Ці модулі повинні надавати функції, які не обов’язково прив’язані до певної бази даних. Це відрізняється від модулів, які завжди прив’язані до певної бази даних під час встановлення (тобто більшість доповнень Odoo). За замовчуванням використовується значення base,web.

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

шлях до альтернативного файл конфігурації. Якщо не визначено, Odoo перевіряє змінну середовища ODOO_RC та розташування за замовчуванням $HOME/.odoorc. Див. розділ файлу конфігурації нижче.

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

Шлях до каталогу для зберігання даних Odoo (наприклад, сховище файлів, сесії). Якщо не вказано, Odoo повернеться до попередньо визначеного шляху. У системах Unix це шлях, визначений у змінній середовища $XDG_DATA_HOME або ~/.local/share/Odoo або /var/lib/Odoo.

-s, --save

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

--without-demo

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

--skip-auto-install

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

--pidfile=<pidfile>

шлях до файлу, де буде збережено pid сервера

--stop-after-init

зупиняє сервер після його ініціалізації.

--geoip-city-db <path>

Абсолютний шлях до файлу бази даних GeoIP City.

--geoip-country-db <path>

Абсолютний шлях до файлу бази даних GeoIP Country.

Тестування

--test-enable

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

--test-file <file>

запускає тестовий файл python

--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 не існує, база даних створюється та встановлюються базові модулі

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

Цей параметр не впливає на cron-процеси. Якщо не вказано –database, cron-процеси працюватимуть на кожній доступній базі даних

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

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

Ел. пошта

--email-from <address>

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

--from-filter <address or domain>

Визначте, до якої адреси електронної пошти застосовуватиметься конфігурація SMTP. Поле може бути доменним іменем або повною адресою електронної пошти, або ж воно може залишатися порожнім. Якщо адреса електронної пошти відправника не відповідає цьому встановленому фільтру, то електронний лист буде інкапсульовано за допомогою комбінації двох системних параметрів: mail.default.from та mail.catchall.domain. Наприклад, «Admin» <[email protected]> => «Admin» <[email protected]>.

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

Для автентифікації має використовуватися SSL-сертифікат. Якщо його встановлено, то потрібен smtp-ssl-private-key.

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

Для автентифікації використовується закритий ключ SSL. Якщо його встановлено, то потрібен smtp-ssl-certificate.

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

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

  • werkzeug: відображати повний трасування на сторінці фронтенду у разі винятку

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-порт для вебсокетних з’єднань у багатопроцесорному режимі або режимі gevent, за замовчуванням 8072. Не використовується в режимі за замовчуванням (потоковий).

--proxy-mode

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

Він ігнорує всі заголовки X-Forwarded-*, якщо X-Forwarded-Host відсутній у запиті.

Він завжди отримує справжню IP-адресу з останнього запису ланцюжка X-Forwarded-For. Налаштуйте свій веб-сервер відповідно, використовуючи директиви, такі як set_real_ip_from у nginx, на випадок, якщо в ланцюжку є інші довірені проксі, які потрібно ігнорувати.

X-Forwarded-Proto та X-Forwarded-Host використовуються для оновлення кореневої URL-адреси запиту, яка, у свою чергу, використовується для оновлення системного параметра web.base.url після успішної автентифікації адміністратора. Цей системний параметр використовується для створення всіх посилань на поточну базу даних; див. Веб-адреса бази даних бази даних.

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

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

--x-sendfile

делегує розсилку файлів вкладень статичному веб-серверу та встановлює http-заголовки X-Sendfile (apache) та X-Accel-* (nginx) у відповідях потоку. Див. Обслуговування статичних файлів і вкладень для налаштування веб-сервера.

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

За замовчуванням Odoo відображає всі журнали level INFO, WARNING та ERROR. Усі журнали незалежно від рівня виводяться на stderr. Доступні різні опції для перенаправлення журналів до інших пунктів призначення та налаштування деталізації.

--logfile <file>

надсилає вивід журналу до вказаного файлу замість stderr. У 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-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>

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

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

--limit-memory-hard <limit>

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

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

М’яке обмеження часу, протягом якого thread/worker cron може існувати до перезапуску, у секундах.

Встановіть значення 0, щоб вимкнути.

За замовчуванням встановлено на 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

shell - Відкрити оболонку

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

$ odoo-bin shell

Example

Додавання знака оклику до всіх імен контактів:

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

Важливо

За замовчуванням оболонка працює в режимі транзакцій. Це означає, що будь-які зміни, внесені до бази даних, відкочуються після виходу з оболонки. Щоб зафіксувати зміни, використовуйте env.cr.commit().

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

Вкажіть бажаний REPL для використання в режимі оболонки. Ця оболонка запускається з уже ініціалізованою змінною env для доступу до ORM та інших модулів Odoo.

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

Середовище

db - Керування базою даних

Ця команда дозволяє керувати базами даних через інтерфейс командного рядка. Операції задаються за допомогою підкоманд.

Для всіх підкоманд доступні такі опції налаштування середовища:

db dump - Збереження дампа бази даних

Створює файл дампа.

$ odoo-bin db dump <database> <dump_path>
database

Назва бази даних для створення дампа.

dump_path

(Необов’язково) База даних виводиться за вказаним шляхом. За замовчуванням вона виводиться на stdout.

--format <zip | dump>

Якщо вказано, база даних вивантажується у вказаному форматі. Підтримувані формати: zip (за замовчуванням), dump (формат pg_dump).

--no-filestore

Якщо вказано, база даних zip створюється без файлового сховища

db load - Завантаження дампа бази даних

Завантажує файл дампа в базу даних Odoo, файл дампа може бути URL-адресою.

$ odoo-bin db load <database> <dump_file>
database

(Необов’язково) Назва бази даних, яку потрібно створити з дампу. Якщо не вказано, використовується назва файлу дампу без розширення.

dump_file

Файл .zip або pg_dump для завантаження.

-f,--force

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

-n,--neutralize

Нейтралізуйте базу даних після її відновлення.

db duplicate - Створення дубліката бази даних

Дублювати базу даних, включаючи файлове сховище.

$ odoo-bin db duplicate <source> <target>
source

Назва вихідної бази даних.

target

Назва цільової бази даних.

-n,--neutralize

Нейтралізуйте базу даних після її відновлення.

-f,--force

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

db rename - Перейменування бази даних

Перейменувати базу даних зі старої назви на нову.

$ odoo-bin db rename <source> <target>
source

Поточна назва бази даних.

target

Нова назва для бази даних.

-f,--force

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

db drop - Видалити базу даних

$ odoo-bin db drop <database>
database

Назва бази даних, яку потрібно видалити.

neutralize - Нейтралізація бази даних

Командний рядок Odoo також дозволяє нейтралізувати базу даних. Команду необхідно виконувати з параметром бази даних.

$ odoo-bin --addons-path <PATH,...> neutralize -d <database>
-d <database>, --database <database>

Вкажіть назву бази даних, яку ви хочете нейтралізувати.

--stdout

Виведіть SQL-код нейтралізації замість його застосування

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

Нейтралізована база даних

scaffold - Створити каркас модуля

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

populate - Заповнити базу даних

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

$ odoo-bin populate
--models <models>

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

--size (small|medium|large)

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

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

cloc - Підрахунок рядків коду

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

$ odoo-bin cloc -c config.conf -d my_database
-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.

-v, --verbose

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

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

З --database опцією

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

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

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

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

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

  • Скрипти міграції, визначені в папках migrations та 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.

obfuscate - Обфускація бази даних

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

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

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

Обфускація симетрична, тому контент можна розшифрувати за допомогою того самого пароля.

Усі конфігурації, доступні для команди сервер, також доступні тут.

$ odoo-bin obfuscate --pwd=<password>
--pwd <password>

(Обов’язково) пароль, який використовуватиметься для симетричного обфускації контенту.

--unobfuscate

якщо ви хочете розшифрквати, а не обфускувати.

--fields <fields>

список записів table.column, розділених комами, для обфускації/розшифровки.

--file <file>

файл, що містить список записів table.column для обфускації/розшифровки.

--exclude

список записів table.column, розділених комами, які не потрібно обфускувати/розшифрувати.

--allfields

використовується лише тоді, коли вибрано --unobfuscate.

Спробуйте розшифрувати всі поля. Це повільніше, ніж вказувати поля вручну.

--vacuum

використовується лише тоді, коли вибрано --unobfuscate.

Після розшифровки повністю очистіть обфусковані таблиці та звільніть невикористаний дисковий простір.

--pertablecommit

комітити один раз для кожної таблиці, після обфускації.

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

-y,--yes

не вимагати ручного підтвердження.

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

deploy - Розгорнути модуль віддалено

Ця команда завантажує модуль на віддалений сервер Odoo та встановлює його. Це простіше, ніж ручне підключення до віддаленого сервера, і не вимагає повного доступу до машини, на якій розміщено екземпляр Odoo, лише адміністративні облікові дані Odoo.

$ odoo-bin deploy <path> <url> --db <dbname> --login <login> --password <password>

Примітка

Передумови:

  • На сервері має бути встановлено модуль base_import_module.

  • Користувач, вибраний за допомогою опції --login, повинен мати права адміністратора.

path

шлях модуля, який буде розгорнуто

url

(Необов’язково) URL-адреса сервера, на якому потрібно розгорнути модуль (за замовчуванням http://localhost:8069)

db <dbname>

назва бази даних (якщо сервер не використовує опцію --db-filter)

--login <username>

ім’я користувача з правами адміністратора (за замовчуванням admin)

--password <password>

пароль користувача з правами адміністратора (за замовчуванням admin)

--verify-ssl

перевірте SSL-сертифікат сервера, щоб переконатися, що цільовий екземпляр є легітимним.

--force

повторно ініціалізуйте модуль, якщо він вже встановлений. Це оновить записи noupdate="1".