Запуск сервера
-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_1,tag_2,...,-tag_n'
выберите тесты для запуска с помощью тегов.
--screenshots
Укажите каталог, в который нужно сохранять снимки экрана при сбое теста HttpCase.browser_js. По умолчанию это /tmp/odoo_tests/db_name/screenshots
--screencasts
Включает скринкасты и назначает каталог для записи файлов скринкастов. Для кодирования кадров в видеофайл необходимо установить утилиту ffmpeg
. В противном случае вместо видеофайла в каталог будут сохранены снимки экрана.
База Данных
-r <user>, --db_user <user>
имя пользователя базы данных, используемое для подключения к PostgreSQL.
-w <password>, --db_password <password>
пароль пользователя базы данных, если используется password authentication.
--db_host <hostname>
адрес сервера базы данных
localhost
в Windows- UNIX сокет для других систем
--db_port <port>
порт, который прослушивает сервер базы данных, по умолчанию 5432
--db-filter <filter>
скрывает базы данных, имена которые не соответствуют <filter>
. Фильтр является регулярным выражением, с дополнениями, которые:
%h
заменяется на полное имя хоста, к которому сделан запрос. (при запросе на www.site.ru - отобразиться только база данных с именем «www.site.ru»).%d
заменяется на имя первого субдомена, к которому сделан запрос, за исключениемwww
(доменodoo.com
иwww.odoo.com
оба соответствуют базе данныхodoo
, например при обращении к subdomain.site.ru будет показана база с именемsubdomain
).Эти операции являются чувствительными к регистру. Добавлена опция
(?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>
При создании новых баз данных на экране управления базами данных указанная база будет использована в качестве шаблона (template database). По умолчанию используется шаблон 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 или long-polling воркеры (при этом остается возможным запустить cron воркеры)
Предупреждение
не действует, если используется параметр --test-enable
,так как для тестов требуется доступный HTTP-сервер
--http-interface <interface>
TCP/IP-адрес, который слушает HTTP-сервер, по умолчанию равен 0.0.0.0
(все адреса)
--http-port <port>
Порт, который слушает HTTP-сервер, по умолчанию равен 8069.
--longpolling-port <port>
TCP-порт для long-polling соединений в многопроцессорном или gevent-режиме, по умолчанию 8072. Не используется в режиме по умолчанию.
--proxy-mode
Позволяет использовать заголовки X-Forwarded-*
через Werkzeug’s proxy support.
Предупреждение
Режим прокси не должен быть включен , если используется внешний обратный прокси-сервер (например nginx)
Ведение логов
По умолчанию Odoo отображает все логирование уровня info
, за исключением логирования рабочего процесса (только warning
), а вывод лога отправляется в stdout
. Доступны различные опции для перенаправления пототока лога в другие пункты назначения, а так же для настройки объема его выходных данных.
--logfile <file>
отправляет поток логов в указанный файл, а не в stdout
. В Unix-системах файл может управляться внешними программами управления логов и автоматически будет вновь открыт при замене
--syslog
отправляет логи в журнал системных событий: syslog на Unix-системах и Event Log на Windows.
Не настраивается
--log-db <dbname>
пишет логи в модель ir.logging
(таблица ir_logging
) текущей базы данных. База данных может иметь имя «current» PostgreSQL, или PostgreSQL URI для, например, сбора логов в одной базе из нескольких установок Odoo.
--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
включить DEBUG уровень логов для HTTP-запросов и ответов можно так --log-handler=odoo.http:DEBUG
--log-sql
включить DEBUG уровень логов для SQL запросов можно вот так --log-handler=odoo.sql_db:DEBUG
--log-level <level>
Ярлык для более простого задания предопределенных уровней для определенных логгеров. «Существующие» уровни (critical
, error
, warn
, debug
) устанавливаются на odoo
и werkzeug
регистраторы (кроме debug
, который установлен только для odoo
).
Odoo также предоставляет отладочные псевдоуровни, которые применяются к различным наборам потоков логов:
debug_sql
устанавливает уровень
debug
для потока логов SQLэквивалентен параметру
--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
используется последний
Multiprocessing
--workers <count>
Если count
не равно 0 (по умолчанию), то включается многопроцессорная обработка и устанавливается указанное количество HTTP воркеров (подпроцессы обрабатывающие HTTP и RPC-запросы).
Примечание
Режим многопроцессорности доступен только в Unix-системах
Ряд параметров позволяет ограничить и переработать воркеры:
--limit-request <limit>
Количество запросов, обрабатываемых воркером до его повторного использования и перезапуска.
По умолчанию - 8196.
--limit-memory-soft <limit>
Максимально допустимая виртуальная память на один воркер. Если предел превышен, воркер будет убит и перезапущен в конце текущего запроса.
По умолчанию 2048MiB.
--limit-memory-hard <limit>
Жесткий лимит на виртуальную память, любой воркер, превысивший лимит, будет немедленно убит, не дожидаясь завершения текущей обработки запроса.
По умолчанию 2560MiB.
--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
сохранит текущее состояние конфигурации обратно в этот файл.
Shell
Командная строка Odoo также позволяет запускать odoo как консольное приложение Python. Это обеспечивает прямое взаимодействие с orm и его функциональными возможностями.
$ odoo_bin shell
--shell-interface (ipython|ptpython|bpython|python)
Укажите предпочитаемый REPL для использования в режиме командной оболочки.
Scaffolding
Scaffolding - это автоматизированное создание каркасной структуры для упрощения первоначальной настройки (создание новых модулей, в случае с Odoo). Хотя это и не обязательно, он позволяет избежать утомительной настройки базовых структур и поиска того, что входит в необходимые требования.
Создание каркаса осуществляется командой odoo-bin scaffold.
name (required)
Имя создаваемого модуля. Может быть «собрано» по определенному вами алгоритму (например: имя каталога модуля, имена моделей, …)
destination (default=current directory)
каталог, в котором создается новый модуль, по умолчанию используется текущий каталог
-t <template>
каталог шаблона, файлы пропускаются через jinja2, затем копируются в каталог destination
(каталог назначения)
$ odoo_bin scaffold my_module /addons/
Это создаст модуль с именем my_module в каталоге /addons/.