コマンドラインインターフェース (CLI)¶

The CLI command-line interface offers several functionalities related to Odoo. You can use it to run the server, launch Odoo as a Python console environment, scaffold an Odoo module, populate a database or count the number of lines of code.

重要

The command to use to call the CLI depends on how you installed Odoo. In the examples below, we assume that you are running Odoo from source with the odoo-bin file. If you installed Odoo from a distribution package or with Docker, you must adapt the command.

Odoo Communityのソースファイルをダウンロードしたディレクトリのルートに移動します。
:command:`./odoo-bin`で全てのCLIコマンドを実行します

ヘルプとバージョン¶

-h, --help¶: 利用可能なすべてのオプションのヘルプテキストを表示します

--version¶: 「Odoo Server 18.0」など、Odoo バージョンを表示します

ちなみに

実行することで、シェルで自動補完を有効にできます。

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

database(s) used when installing or updating modules. providing a comma-separated list restrictions to access to database.

For advanced database options, take a look below.

-i <modules>, --init <modules>¶: サーバを実行する前にインストールするモジュールのカンマ区切りリスト ( :option:`-d`が必要)。

-u <modules>, --update <modules>¶: サーバを実行する前に更新するモジュールのカンマ区切りのリストです。すべてのモジュールには all を使用してください。( :option:`-d`が必要です)。

--addons-path <directories>¶: モジュールが格納されているディレクトリのカンマ区切りリスト。これらのディレクトリはモジュールをスキャンします。

--upgrade-path <upgrade_path>¶: 追加のアップグレードスクリプトがロードされるディレクトリのカンマ区切りのリストです。

--pre-upgrade-scripts <pre_upgrade_scripts>¶: スクリプトをアップグレードするパスをカンマ区切りでリストします。任意のモジュールのアップグレードが要求された場合、ベースモジュールをロードする前にスクリプトを実行します。これは、大規模なアップグレード後にカスタムモジュールのアップグレード中にいくつかのアクションを実行するのに便利です。

--load <modules>¶: サーバ全体のモジュールのリスト。これらのモジュールは特定のデータベースに関連付けられていない機能を提供することになっています。これは、インストール時には常に特定のデータベースにバインドされるモジュールとは対照的です (i. を選択します。 Odoo アドオンの大半です。デフォルトは base,web です。

-c <config>, --config <config>¶: path to an alternate configuration file. If not defined, Odoo checks ODOO_RC environmental variable and default location $HOME/.odoorc. See configuration file section below.

-D <data-dir-path>, --data-dir <data-dir-path>¶: Odooデータを格納するディレクトリパス（例：filestore、sessions）。指定しない場合、Odooは事前定義されたパスにフォールバックします。 Unix システムでは、$XDG_DATA_HOME`環境変数または :file:`~/.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シティデータベースファイルへの絶対パスです。

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

`-`では、この仕様に一致するテストを含めるか除外するかを指定します。
The tag will match tags added on a class with a tagged() decorator (all test classes have standard and at_install tags until explicitly removed, see the decorator documentation).
* はすべてのタグに一致します。
include モードでタグが省略された場合、その値は standard になります。
除外モードでタグが省略された場合、値は * です。
モジュール名、クラス名、およびメソッドはそれぞれモジュール名、テストクラス名、テストメソッド名と一致します。

モジュールのインストール/更新とモジュールのロード終了直後にテストのフィルタリングと実行が2回行われます。各段階でテストは --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>¶

データベースサーバのホスト

localhost on Windows
それ以外の場合 UNIX ソケット

--db_port <port>¶: データベースの listen をポートします。デフォルトは 5432 です。

--db-filter <filter>¶

<filter> に一致しないデータベースを非表示にします。フィルタは regular expression で、次のように追加します。

%h はリクエストが行われたホスト名全体に置き換えられます。
%d は、リクエストが行われたサブドメインに置き換えられます。例外は www です。 om`` と www.odoo.com はデータベースの odoo と一致します。

これらの操作は大文字と小文字を区別します。すべてのデータベースに一致させるオプション (?i) を追加します。(?i)%d を使用してドメイン odoo.com はデータベース Odoo と一致します。

バージョン11以降。 --databaseパラメータとカンマ区切りのデータベースリストを指定することで、指定されたデータベースのlistenへのアクセスを制限することもできます。

2つのパラメータを組み合わせると、db-filter は、データベースリストを制限するためのカンマ区切りのデータベースリストに置き換えられます。一方、コンマ区切りリストはモジュールのアップグレードなどの要求された操作を実行するために使用されます。

$ odoo-bin --db-filter ^11.*$

11から始まるデータベースへのアクセスを制限する

$ odoo-bin --database 11firstdatabase,11seconddatabase

2つのデータベース、11firstdatabaseと11seconddatabaseへのアクセスを制限する

$ odoo-bin --database 11firstdatabase,11seconddatabase -u base

2つのデータベース、11firstdatabaseと11seconddatabaseへのアクセスを制限し、1つのデータベースのベースモジュールを更新します: 11firstdatabase。データベース11seconddatabaseが存在しない場合、データベースが作成され、ベースモジュールがインストールされます。

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

名前が 11 で始まるデータベースへのアクセスを制限し、1 つのデータベースのベースモジュールを更新します: 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¶: 新しいデータベースを作成するときにアクセントのない拡張機能を有効にしてみてください。

E-mail¶

--email-from <address>¶: Odooがメールを送信する必要がある場合、 <FROM> として使用されるメールアドレス

--from-filter <address or domain>¶: SMTP設定が適用されるメールアドレスを定義します。この項目は、ドメイン名またはメールアドレス全体であるか、または空のままにすることができます。送信者のメールアドレスがこの設定のフィルターと一致しない場合次に、電子メールは2つのシステムパラメータの組み合わせを使用してカプセル化されます: mail。 efault.from と mail.catchally.domain 。例えば、"Admin" <admin@example.com> => "Admin" <notifications@mycompany.com>.

--smtp <server>¶: メールを送信するために接続するSMTPサーバーのアドレス

--smtp-port <port>¶

--smtp-ssl¶: 設定されている場合、doo は 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ファイルから次のupdate/initまで読み込まれません。特に、テンプレートはこのオプションを使用して翻訳されません。
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 モードでの Web ソケット接続の TCP ポート、デフォルトは 8072 です。デフォルト(スレッド)モードでは使用されません。

--proxy-mode¶

Werkzeugのプロキシサポート`_を介して``X-Forwarded-*` ヘッダーを使用することができます。

リクエストから X-Forwarded-* が見つからない場合は、すべての X-Forwarded-* ヘッダーを無視します。

X-Forwarded-For チェーンの最後のエントリから、常に実際の IP を取得します。 nginx の set_real_ip_from のようなディレクティブを使用して、チェーンに信頼できるプロキシがある場合には無視される必要があります。

X-Forwarded-Proto と X-Forwarded-Host はリクエストのルート URL を更新するために使用されます。これは ``web.base の更新に使用されます。 admin認証が成功するとrl``システムパラメータ。このシステムパラメータは現在のデータベースのすべてのリンクを生成するために使用されます。 Web base URL of a database を参照してください。

警告

プロキシモードはリバースプロキシシナリオ外で有効にしないでください

--x-sendfile¶: 添付ファイルを静的なWebサーバーに提供し、ストリーム応答で``X-Sendfile`` (apache) と X-Accel-* (nginx) の両方のヘッダを設定します。ウェブサーバーの設定については、静的ファイルと添付ファイルの提供を参照してください。

ログ管理¶

デフォルトでは、Odoo は INFO 、 WARNING および ERROR のすべてのログを表示します。すべてのログは stderr に出力されます。ロギングを他のデスティネーションにリダイレクトし、冗長性をカスタマイズするためのさまざまなオプションが利用できます。

--logfile <file>¶: ログ出力を stderr の代わりに指定したファイルに送信します。 Unix では、外部ログローテーションプログラムで管理でき、置き換えると自動的に再開されます。

--syslog¶

システムのイベントロガーにログを記録します: syslog on unices and the Event Log on Windows

設定されていません

--log-db <dbname>¶: 指定したデータベースの ir_logging モデル (ir_logging テーブル) にログを記録します。データベースは、"current" PostgreSQL内のデータベースの名前、例えばログの集計のために`a PostgreSQL URI`_ することができます。

--log-handler <handler-spec>¶

LOGGER:LEVEL、提供された LEVEL 例えば odoo で ``LOGGER を有効にします。 odels:DEBUG`` はモデル内の DEBUG レベル以上のすべてのロギングメッセージを有効にします。

コロン : は必須です
ロガーは、ルート (デフォルト) ハンドラを構成するために省略できます。
レベルを省略すると、ロガーは INFO に設定されます。

このオプションは、複数のロガーを設定するために繰り返すことができます。例:

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

--log-web¶: --log-handler=odoo.http:DEBUG と同等のHTTPリクエストとレスポンスのDEBUGロギングを有効にします

--log-sql¶: --log-handler=odoo.sql_db:DEBUG と同等のSQLクエリのDEBUGログを有効にします。

--log-level <level>¶

特定のロガーにあらかじめ定義されたレベルを簡単に設定するショートカット。 "real" levels (critial, error, warn, debug) は odoo と werkzeug ロガーに設定されています (odoo のみに設定されている debug を除く)。

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> 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 です。

設定ファイル¶

ほとんどのコマンドラインオプションは、設定ファイルを介して指定することもできます。ほとんどの場合、プレフィックスの - が削除され、その他の - は _ eに置き換えられます。 --db-template は db_template になります。

いくつかの変換パターンが一致しません:

--db-filter は dbfilter になります
--no-http は http_enable ブールに対応します
プリセットのロギング( --log-handler と --log-db`を除くすべてのオプション) は ``log_handler` にコンテンツを追加します。これを設定ファイルに直接使用する
--smtp は smtp_server として保存されます。
--database は db_name として保存されています
--i18n-import と --i18n-export は設定ファイルからは全く利用できません

The default configuration file is $HOME/.odoorc which can be overridden using --config. Specifying --save will save the current configuration state back to that file. The configuration items relative to the command-line are to be specified in the section [options].

ここにサンプルファイルがあります:

[options]
db_user=odoo
dbfilter=odoo

シェル¶

Odoo コマンドラインは Python コンソール環境として Odoo を起動することができ、 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を指定します。このシェルは、ORMやその他のOdooモジュールにアクセスできるようにすでに初期化されている env 変数から始まります。

関連項目

環境

中和する¶

Odoo コマンドラインでもデータベースを中和することができます。このコマンドはデータベースオプションで実行する必要があります。

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

-d <database, --database <database>¶: 無効化するデータベース名を指定します。

--stdout¶: 適用する代わりに中和SQLを出力する

関連項目

安全化データベース

Scaffold¶

Scaffolding は、(Odoo の場合、新しいモジュールの) ブートストラップを簡素化するためのスケルトン構造を自動的に作成することです。必要ではありませんが、基本的な構造を設定し、すべての開始要件が何であるかを調べることの退屈を回避します。

Scaffolding は :command:の odoo-bin scaffold サブコマンドで利用できます。

$ odoo-bin scaffold my_module /addons/

name (required)¶: 作成するモジュールの名前は、プログラム名を生成するために様々なマナーで割り当てられることがあります（例えば、モジュールディレクトリ名、モデル名、 …）

destination (default=current directory)¶: 新しいモジュールを作成するディレクトリ、デフォルトはカレントディレクトリです

-t <template>¶: テンプレートディレクトリ、ファイルはjinja2_を通して渡され、destination ディレクトリにコピーされます。

これは my_module というモジュールをディレクトリ*/addons/* に作成します。

データベースの数¶

Odoo Populateでは、指定されたデータベース内の既存のデータを複製することができます。これは、大きなテーブルが必要な場合のテストやベンチマークに使用できます。複製プロセスでは、 UNIQUE 制約を尊重するためのいくつかのフィールドのバリエーションが導入されます。x2多くの関係に従います。

$ 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 と組み合わせると、両方のオプションの結果の合計数になります(重複の可能性があります)。 処理するコードを指定するには、少なくともこれらの 2 つのオプションの 1 つが必要です。

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

関連項目

reference/cmdline/clock/database-option

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

指定されたパス内のファイルを処理します。

--database と組み合わせると、両方のオプションの結果の合計にカウントされます (重複の可能性あり)。処理するコードを指定するには、少なくともこれらの 2 つのオプションの 1 つが必要です。

$ odoo-bin cloc -p addons/account

オプションを繰り返すことで、複数のパスを提供することができます。

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

関連項目

reference/cmdline/clock/path-option

--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)
フォルダ :file:`static/lib`の内容
The tests defined in the folder tests and static/tests
フォルダ :file:`migrations`と`upgrades`で定義されたマイグレーションスクリプト。
マニフェストの demo または demo_xml セクションで宣言された XML ファイル

特別なケースでは、Odoo Cloc で無視すべきファイルのリストをモジュールごとに定義することができます。これはマニフェストの clock_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` オプションで¶

このメソッドは、マニフェストファイルが指定されたフォルダに存在する場合、 :ref:`--databaseオプション <reference/cmdline/cloc/database-option>と同じ動作をします。そうでなければ、それはすべてのファイルをカウントします。

追加モジュールの識別¶

標準モジュールと追加モジュールを区別するために、Odoo Cloc は以下のヒューリスティックを使用します。(実際のファイルシステムパス) base や web や web_enterprise の標準モジュールと同じ親ディレクトリの中で標準と見なされます。その他のモジュールは追加のモジュールとして扱われます。

エラー処理¶

一部のファイルは、Odoo Klocwork でカウントできません。これらのファイルは、出力の最後に報告されます。

最大ファイルサイズを超えました¶

Odoo Cloc は 25 MB を超えるファイルを拒否します。通常、ソースファイルは 1 MB より小さいです。ファイルが拒否された場合、次のようになります。

多くのデータを含む生成された XML ファイル。マニフェスト内で除外する必要があります。
:file:`static/lib`フォルダに配置するJavaScriptライブラリ。

構文エラー¶

Odoo Cloc は、Python ファイルのコード行を構文の問題でカウントできません。追加のモジュールにそのようなファイルが含まれている場合は、モジュールの読み込みを許可するように修正する必要があります。モジュールがこれらのファイルの存在にもかかわらず動作する場合、それらはおそらく読み込まれないため、モジュールから削除する必要があります。または少なくとも clock_exclude を介してマニフェスト内で除外します。

TSConfig ジェネレーター¶

javascriptで作業する場合は、強力な自動補完機能を提供するエディタを支援する方法があります。これらの方法の1つは、tsconfig.jsonファイルを使用する方法です。元々はtypescriptを意味していましたが、エディタはプレーンなjavascriptで情報を使用することができます。この設定ファイルを使用すると、モジュール間で完全な自動補完が可能になります。

このファイルを生成するコマンドは、必要に応じて無名の引数を取得します。これらは、アドオンディレクトリへの相対パスです。以下の例では、communityとenterpriseを含むフォルダにtsconfigファイルを保存するフォルダを1つ上に移動します。

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

コマンドラインインターフェース (CLI)¶

ヘルプとバージョン¶

サーバーの実行¶

テストの構成¶

データベース¶

E-mail¶

国際化¶

詳細オプション¶

開発者向け機能¶

HTTP¶

ログ管理¶

マルチ処理¶

設定ファイル¶

シェル¶

中和する¶

Scaffold¶

データベースの数¶

Cloc¶

コマンドラインオプション¶

処理済みファイル¶

--database オプションで¶

--path オプションで¶

追加モジュールの識別¶

エラー処理¶

最大ファイルサイズを超えました¶

構文エラー¶

TSConfig ジェネレーター¶

`--database` オプションで¶

`--path` オプションで¶