命令行界面(CLI)

命令行界面(CLI,即 command-line interface)提供多种与 Odoo 相关的功能。您可以用它来 运行服务器、把 Odoo 作为 Python 控制台环境启动、生成 Odoo 模块脚手架、填充数据库 或 统计代码行数。

Important

调用 CLI 的命令取决于您的 Odoo 安装方式。在下面的示例中,我们假设您使用 odoo-bin 文件 从源码运行 Odoo。如果您是通过 发行版软件包 或 Docker 安装的 Odoo,则需要相应调整命令。

  1. 进入您下载的 Odoo Community 源文件所在目录的根目录。

  2. 使用 ./odoo-bin 运行所有 CLI 命令

帮助与版本

-h, --help

显示包含所有可用选项的帮助文本

--version

显示 Odoo 版本,例如 “Odoo Server 18.0”

Tip

您可以通过运行以下命令在 shell 中启用自动补全

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>

以逗号分隔的模块列表,在运行服务器前更新。使用 all 表示所有模块。(需要 -d)。

--addons-path <directories>

以逗号分隔的目录列表,模块存放于这些目录中。系统会扫描这些目录以查找模块。

--upgrade-path <upgrade_path>

以逗号分隔的目录列表,用于加载额外的升级脚本。

--pre-upgrade-scripts <pre_upgrade_scripts>

以逗号分隔的升级脚本路径列表。当请求升级任何模块时,这些脚本会在加载 base 模块之前运行。这有助于在大版本升级后的自定义模块升级过程中执行一些操作。

--load <modules>

要加载的服务器级模块列表。这些模块提供的功能不一定与特定数据库绑定。与之相对的是安装时始终绑定到特定数据库的模块(即大多数 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。

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

以逗号分隔的规格(spec)列表,用于筛选要执行的测试。设置后将启用单元测试。

示例:--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>

数据库密码,在使用 password authentication 时填写。

--db_host <hostname>

数据库服务器主机

  • Windows 上为 localhost

  • 其他情况为 UNIX 套接字

--db_port <port>

数据库监听的端口,默认为 5432

--db-filter <filter>

隐藏与 <filter> 不匹配的数据库。该过滤器是一个 regular expression,并有如下补充:

  • %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 上更新 base 模块。如果数据库 11seconddatabase 不存在,则会创建该数据库并安装 base 模块

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

限制仅访问名称以 11 开头的数据库,并在其中一个数据库 11firstdatabase 上更新 base 模块。如果数据库 11seconddatabase 不存在,则会创建该数据库并安装 base 模块

--db-template <template>

在数据库管理界面创建新数据库时,使用指定的 template database。默认值为 template0。

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

数据库管理器用于转储和恢复数据库的 PostgreSQL 可执行文件所在路径。仅当这些可执行文件位于非标准目录时才需要指定此选项。

--no-database-list

禁止列出系统上可用的数据库

--db_sslmode

控制 Odoo 与 PostgreSQL 之间连接的 SSL 安全性。取值应为 ‘disable’、’allow’、’prefer’、’require’、’verify-ca’ 或 ‘verify-full’,默认值为 ‘prefer’

--unaccent

在创建新数据库时尝试启用 unaccent 扩展

电子邮件

--email-from <address>

Odoo 需要发送邮件时用作 <FROM> 的电子邮件地址

--from-filter <address or domain>

定义 SMTP 配置应用于哪个电子邮件地址。该字段可以是域名或完整的电子邮件地址,也可以留空。如果发件人的电子邮件地址与此过滤器不匹配,则该邮件将使用两个系统参数 mail.default.from 和 mail.catchall.domain 的组合进行封装。例如,”Admin” <admin@example.com> => “Admin” <notifications@mycompany.com>。

--smtp <server>

用于发送邮件而连接的 SMTP 服务器地址

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

若设置,则 Odoo 应使用 SSL/STARTSSL SMTP 连接

--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:直接从 xml 文件而非数据库读取 QWeb 模板。模板一旦在数据库中被修改,在下一次更新 / 初始化之前将不再从 xml 文件读取。特别是,使用此选项时模板不会被翻译。

  • reload:python 文件更新时重启服务器(取决于所用的文本编辑器,可能无法检测到)

  • qweb:当节点包含 t-debug='debugger' 时在 QWeb 模板求值处中断

  • (i)p(u)db:在记录并返回错误之前,若出现意外错误则在代码中启动所选的 Python 调试器。

  • werkzeug:出现异常时在前端页面显示完整的回溯信息

HTTP

--no-http

不启动 HTTP 或长轮询工作进程(仍可能启动 cron 工作进程)

Warning

若设置了 --test-enable 则无效,因为测试需要可访问的 HTTP 服务器

--http-interface <interface>

HTTP 服务器监听的 TCP/IP 地址,默认为 0.0.0.0 (所有地址)

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

HTTP 服务器监听的端口,默认为 8069。

--gevent-port <port>

多进程或 gevent 模式下用于 websocket 连接的 TCP 端口,默认为 8072。默认(线程)模式下不使用。

--proxy-mode

通过 Werkzeug’s proxy support 启用对 X-Forwarded-* 头的使用。

如果请求中缺少 X-Forwarded-Host,则会忽略所有 X-Forwarded-* 头。

它始终从 X-Forwarded-For 链的最后一项获取真实 IP。如果链上还有其他必须忽略的可信代理,请相应地配置 Web 服务器,例如使用 nginx 的 set_real_ip_from 指令。

X-Forwarded-Proto 和 X-Forwarded-Host 用于更新请求的根 URL,而根 URL 又用于在管理员成功认证后更新 web.base.url 系统参数。该系统参数用于为当前数据库生成所有链接;参见 数据库的 Web 基本 URL。

Warning

代理模式 不得 在反向代理场景之外启用

--x-sendfile

将附件文件的提供委托给静态 Web 服务器,并在流式响应上同时设置 X-Sendfile (apache) 和 X-Accel-* (nginx) HTTP 头。Web 服务器配置参见 提供静态文件和附件。

日志

默认情况下,Odoo 显示 level 为 INFO、WARNING 和 ERROR 的所有日志。所有日志无论级别如何均输出到 stderr。可以使用多种选项将日志重定向到其他目标并自定义详细程度。

--logfile <file>

将日志输出发送到指定文件而非 stderr。在 Unix 上,该文件 可由外部日志轮转程序管理 ,被替换后会自动重新打开

--syslog

记录到系统的事件日志:Unix 上的 syslog 和 Windows 上的 Event Log。

两者均不可配置

--log-db <dbname>

记录到指定数据库的 ir.logging 模型(ir_logging 表)。数据库可以是”当前” PostgreSQL 中的数据库名,或用于日志聚合等用途的 PostgreSQL URI。

--log-handler <handler-spec>

LOGGER:LEVEL,以指定的 LEVEL 启用 LOGGER,例如 odoo.models:DEBUG 将启用 models 中所有 DEBUG 级别及以上的日志消息。

  • 冒号 : 是必需的

  • 可以省略记录器名称以配置根(默认)处理器

  • 如果省略级别,记录器将被设置为 INFO

该选项可重复使用以配置多个记录器,例如

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

启用 HTTP 请求和响应的 DEBUG 日志,等同于 --log-handler=odoo.http:DEBUG

--log-sql

启用 SQL 查询的 DEBUG 日志,等同于 --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

Note

当 --log-level 与 --log-handler 冲突时,以后者为准

多进程

--workers <count>

如果 count 不为 0(默认值),则启用多进程模式并启动指定数量的 HTTP 工作进程(处理 HTTP 和 RPC 请求的子进程)。

Note

多进程模式仅在基于 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> 秒的 CPU 时间。如果超出限制,工作进程将被终止。

默认为 60。

--limit-time-real <limit>

防止工作进程处理请求所耗时间超过 <limit> 秒。如果超出限制,工作进程将被终止。

与 --limit-time-cpu 的区别在于这是一个”实际时间”限制,包含 SQL 查询等耗时。

默认为 120。

--max-cron-threads <count>

专门用于 定时任务 的工作进程数量。默认为 2。多线程模式下为线程,多进程模式下为进程。

在多进程模式下,此数量是在 HTTP 工作进程之外额外增加的。

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

定时任务 线程/工作进程在重启前允许存活时长的软限制,单位为秒。

设为 0 表示禁用。

默认为 0。

配置文件

大多数命令行选项也可以通过配置文件指定。大多数情况下,它们的名称类似,去掉前缀 -,其余 - 替换为 _,例如 --db-template 变为 db_template。

部分转换不符合此模式:

默认配置文件为 $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()

Important

默认情况下,shell 以事务模式运行。这意味着对数据库所做的任何更改都会在退出 shell 时回滚。要提交更改,请使用 env.cr.commit()。

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

指定 shell 模式下首选使用的 REPL。该 shell 启动时 env 变量已初始化,可以访问 ORM 和其他 Odoo 模块。

更多内容

环境

中和

Odoo 命令行也支持对数据库进行中和处理。该命令必须带有数据库选项运行。

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

指定要中和的数据库名称。

--stdout

输出中和 SQL 而不是执行它

更多内容

存档数据库

脚手架

脚手架是自动创建骨架结构以简化引导过程(就 Odoo 而言是新模块)的机制。虽然并非必需,但它避免了设置基础结构和查找所有初始要求的繁琐工作。

可通过 odoo-bin scaffold 子命令使用脚手架功能。

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

要创建的模块名称,会以多种方式变换以生成程序化名称(例如模块目录名、模型名称等)

destination (default=current directory)

创建新模块的目录,默认为当前目录

-t <template>

模板目录,文件先经 jinja2 处理,然后复制到 destination 目录

这将在 /addons/ 目录中创建模块 my_module。

数据库数据填充

Odoo Populate 允许复制指定数据库中的现有数据。当需要大表时可用于测试和基准测试。复制过程会为某些字段引入变化,以满足 UNIQUE 约束等要求。它还会处理 x2Many 关系。

$ odoo-bin populate -d  my_database --models res.partner,account.move --factors 1000
-d <database>

要填充的数据库的名称

--models

要填充的模型列表。出现两次的模型只会被填充一次。

--factors

填充因子列表。如果某个模型缺少因子,将使用列表中的最后一个因子。

--sep

用于生成记录名称的分隔符

Cloc

Odoo Cloc 是一个统计以 Python、Javascript、CSS、SCSS 或 XML 编写的相关代码行数的工具。可用作对额外模块维护计费的粗略指标。

命令行选项

-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 会统计指定数据库中已安装的额外模块每个文件的行数。此外,它还会统计直接在数据库中创建或导入的服务器动作和自定义计算字段的 Python 行数。最后,它还会统计导入模块中 Javascript、CSS 和 SCSS 文件以及 QWeb 视图的代码行数。

默认情况下,以下文件不计入统计:

  • 清单文件(__manifest__.py 或 __openerp__.py)

  • static/lib 文件夹的内容

  • 定义在 tests 和 static/tests 文件夹中的测试

  • 定义在 migrations 和 upgrades 文件夹中的迁移脚本

  • 在清单的 demo 或 demo_xml 部分中声明的 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 会拒绝任何大于 25MB 的文件。通常源文件小于 1 MB。如果某个文件被拒绝,它可能是:

  • 包含大量数据的生成 XML 文件。应在清单中将其排除。

  • 应放置在 static/lib 文件夹中的 JavaScript 库。

语法错误

Odoo Cloc 无法统计存在语法问题的 Python 文件的代码行数。如果某个插件模块包含此类文件,应将其修复以使模块能够加载。如果模块在这些文件存在的情况下仍能正常运行,则这些文件很可能并未被加载,因此应从模块中移除,或至少在清单中通过 cloc_exclude 予以排除。

TSConfig 生成器

在开发 JavaScript 时,有一些方法可以帮助您的编辑器提供强大的自动补全功能。其中一种方式是使用 tsconfig.json 文件。它最初是为 TypeScript 设计的,编辑器也可以在纯 JavaScript 中使用其信息。有了这个配置文件,您现在可以在所有模块间获得完整的自动补全。

生成这些文件的命令可以接受任意数量的未命名参数,它们是指向您的插件模块目录的相对路径。在下面的示例中,我们向上移动一层文件夹,将 tsconfig 文件保存在包含社区版和企业版的文件夹中。

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