命令行界面 (CLI)

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

重要

调用 CLI 的命令取决于您如何安装 Odoo。在下面的示例中，我们假设您是 通过源码运行 Odoo （使用 odoo-bin 文件）。如果您是通过 分发包 或 Docker 安装的 Odoo，则需要调整命令。

  1. 导航到您下载 Odoo 社区版源文件的根目录。

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

帮助与版本

-h, --help

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

--version

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

小技巧

您可以通过运行以下命令在 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>

升级脚本路径的逗号分隔列表。当请求任何模块的升级时，这些脚本会在加载基础模块之前运行。这在主版本升级后执行自定义模块升级时非常有用。

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

存储服务器进程 ID 的文件路径

--stop-after-init

在初始化完成后停止服务器。

--geoip-city-db <path>

GeoIP 城市数据库文件的绝对路径。

--geoip-country-db <path>

GeoIP 国家数据库文件的绝对路径。

测试配置

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

数据库密码，如果使用 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) 以匹配所有数据库（因此使用 (?i)%d 的域名 odoo.com 匹配数据库 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

控制 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/STARTTLS 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 工作进程）

警告

如果设置了 --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。如果有其他需要忽略的受信任代理，请使用如 nginx 的 set_real_ip_from 等指令相应配置您的 Web 服务器。

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

警告

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

--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 上的事件日志 。

两者均不可配置

--log-db <dbname>

记录到指定数据库中的 ir.logging 模型（ ir_logging 表）。数据库可以是“当前”PostgreSQL 中的数据库名称，也可以是用于日志聚合的 PostgreSQL URI 。

--log-handler <handler-spec>

LOGGER:LEVEL，在提供的 LEVEL 启用 LOGGER ，例如 odoo.models:DEBUG 将在模型中启用所有等于或高于 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

注解

如果 --log-level 和 --log-handler 之间存在冲突，则使用后者

多进程

--workers <count>

如果 count 不为 0（默认值为 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> 的 CPU 秒数。如果超出限制，工作进程将被终止。

默认值为 60。

--limit-time-real <limit>

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

与 --limit-time-cpu 不同，这是一个包含“实际时间”的限制，例如 SQL 查询的时间。

默认值为 120。

--max-cron-threads <count>

专用于 cron 任务的工作进程数量。默认值为 2。在多线程模式下，这些工作进程是线程；在多进程模式下，它们是进程。

对于多进程模式，这是在 HTTP 工作进程之外的额外进程。

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

一个 cron 线程/工作进程在被重启之前的生存时间软限制，以秒为单位。

设置为 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()

重要

默认情况下，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 的文件。通常，源文件小于 1MB。如果某个文件被拒绝，可能是因为：

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

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

语法错误

Odoo Cloc 无法统计存在语法问题的 Python 文件的代码行数。如果额外模块包含此类文件，应修复它们以允许模块加载。如果模块尽管存在这些文件仍能正常工作，那么这些文件可能未被加载，因此应从模块中移除它们，或者至少通过 cloc_exclude 在清单文件中排除。

TSConfig 生成器

在处理 JavaScript 时，有一些方法可以帮助编辑器提供强大的自动补全功能。其中一种方法是使用 tsconfig.json 文件。虽然它最初是为 TypeScript 设计的，但编辑器也可以将其信息应用于纯 JavaScript。通过此配置文件，您现在可以在模块之间实现完整的自动补全。

生成这些文件的命令可以接受任意数量的未命名参数。这些参数是您的插件目录的相对路径。在下面的示例中，我们向上移动一级文件夹，以便将 tsconfig 文件保存在包含 community 和 enterprise 的文件夹中。

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