Files
odoo-docs/content/developer/reference/cli.rst
Krzysztof Magusiak (krma) b44dfce306 [IMP] developer/cli: config option for system database
odoo/odoo#239487

closes odoo/documentation#15656

Signed-off-by: Krzysztof Magusiak (krma) <krma@odoo.com>
2025-12-11 17:56:49 +00:00

1620 lines
48 KiB
ReStructuredText

.. _reference/cmdline:
============================
Command-line interface (CLI)
============================
The CLI :dfn:`command-line interface` offers several functionalities related to Odoo. You can use it
to :ref:`run the server <reference/cmdline/server>`, :ref:`launch Odoo as a Python console
environment <reference/cmdline/shell>`, :ref:`scaffold an Odoo module <reference/cmdline/scaffold>`,
:ref:`populate a database <reference/cmdline/populate>` or :ref:`count the number of lines of code <reference/cmdline/cloc>`.
.. important::
The command to use to call the CLI depends on how you installed Odoo. In the examples below, we
assume that you are :doc:`running Odoo from source </administration/on_premise/source>` with the
:file:`odoo-bin` file. If you installed Odoo :doc:`from a distribution package
</administration/on_premise/packages>` or with `Docker <https://hub.docker.com/_/odoo/>`_, you
must adapt the command.
.. tabs::
.. tab:: Run Odoo from source
#. Navigate to the root of the directory where you downloaded the source files of Odoo
Community.
#. Run all CLI commands with :command:`./odoo-bin`
.. tab:: Odoo was installed from a distribution package
When Odoo was installed, an executable named `odoo` was added to your user's PATH. Replace
all occurrences of :command:`odoo-bin` with :command:`odoo` in the examples below.
.. tab:: Odoo was installed with Docker
Please refer to the `documentation of the official Docker image of Odoo
<https://hub.docker.com/_/odoo/>`_.
.. _reference/cmdline/extra:
Version
=======
.. program:: odoo-bin
.. option:: -h, --help
it can be used in combination with any command available, and it displays
the options of the current command.
If no command is used, it will act as per the `help` command
:ref:`below <reference/cmdline/help>`.
.. option:: --version
shows Odoo version e.g. "Odoo Server {BRANCH}"
.. tip:: You can enable auto-completion in your shell by running
.. code-block:: bash
COMMANDS=$(odoo-bin --help | sed -e "s/^ \([^ ]\+\).*$/ \1/gp;d" | xargs)
echo "complete -W '$COMMANDS' odoo-bin" >> ~/.bash_completion
.. _reference/cmdline/help:
`help` - Show available commands
================================
.. program:: odoo-bin help
This command shows all the available commands for Odoo.
It has no options.
.. _reference/cmdline/server:
`server` - Run the Server
=========================
.. program:: odoo-bin
This command is the default one: you can omit it, and it will be chosen anyway.
.. option:: -d <database>, --database <database>
database(s) used when installing or updating modules.
Providing a comma-separated list restrict access to databases provided in
list.
For advanced database options, take a look :ref:`below <reference/cmdline/server/database>`.
.. option:: -i <modules>, --init <modules>
comma-separated list of modules to install before running the server (requires :option:`-d`).
.. option:: -u <modules>, --update <modules>
comma-separated list of modules to update before running the server.
Use ``all`` for all modules. (requires :option:`-d`).
.. option:: --reinit <modules>
A comma-separated list of modules to reinitialize before starting the server.
(requires :option:`-d`).
The reinitialization is similar to a simple upgrade without executing any upgrade script.
It loads data in ``init`` mode instead of ``update`` mode, primarily affecting records marked as ``'noupdate'``.
All modules that depend directly or indirectly on the specified ones will also be reinitialized.
This option is intended for debugging or development purposes only.
**Do not use it with a production database.**
.. option:: --addons-path <directories>
comma-separated list of directories in which modules are stored. These
directories are scanned for modules.
.. (nb: when and why?)
.. option:: --upgrade-path <upgrade_path>
comma-separated list of directories from which additional upgrade scripts
are loaded.
.. option:: --pre-upgrade-scripts <pre_upgrade_scripts>
comma-separated list of paths to upgrade scripts. The scripts are run before
loading base module when an upgrade of any module is requested. This is
useful to perform some actions during custom modules upgrade after a major
upgrade.
.. option:: --load <modules>
list of server-wide modules to load. Those modules are supposed to provide
features not necessarily tied to a particular database. This is in contrast
to modules that are always bound to a specific database when they are
installed (i.e. the majority of Odoo addons). Default is ``base,web``.
.. option:: -c <config>, --config <config>
path to an alternate :ref:`configuration file <reference/cmdline/config>`.
If not defined, Odoo checks ``ODOO_RC`` environmental variable
and default location :file:`{$HOME}/.odoorc`.
See configuration file section :ref:`below <reference/cmdline/config>`.
.. option:: -D <data-dir-path>, --data-dir <data-dir-path>
directory path where to store Odoo data (eg. filestore, sessions).
If not specified, Odoo will fallback
to a predefined path. On Unix systems its
one defined in ``$XDG_DATA_HOME`` environmental variable
or :file:`~/.local/share/Odoo` or :file:`/var/lib/Odoo`.
.. option:: -s, --save
saves the server configuration to the current configuration file
(:file:`{$HOME}/.odoorc` by default, and can be overridden using
:option:`-c`).
.. option:: --with-demo
install demo data in new databases.
.. option:: --without-demo
don't install demo data nor in new databases nor when installing new
modules in a database that uses demo data, this is the default.
.. option:: --pidfile=<pidfile>
path to a file where the server pid will be stored
.. option:: --stop-after-init
stops the server after its initialization.
.. option:: --geoip-city-db <path>
Absolute path to the GeoIP City database file.
.. option:: --geoip-country-db <path>
Absolute path to the GeoIP Country database file.
.. _reference/cmdline/testing:
Testing
-------
.. option:: --test-enable
runs tests after module installation
.. option:: --test-file <file>
runs a python test file
.. option:: --test-tags [-][tag][/module][:class][.method]
Comma-separated list of specs to filter which tests to execute. Enable unit tests if set.
Example: `--test-tags :TestClass.test_func,/test_module,external`
* The `-` specifies if we want to include or exclude tests matching this spec.
* The tag will match tags added on a class with a :func:`~odoo.tests.common.tagged` decorator
(all :ref:`test classes <reference/testing>` have `standard` and `at_install` tags
until explicitly removed, see the decorator documentation).
* `*` will match all tags.
* If tag is omitted on include mode, its value is `standard`.
* If tag is omitted on exclude mode, its value is `*`.
* The module, class, and method will respectively match the module name, test class name and test method name.
Filtering and executing the tests happens twice: right
after each module installation/update and at the end
of the modules loading. At each stage tests are filtered
by `--test-tags` specs and additionally by dynamic specs
`at_install` and `post_install` correspondingly.
.. option:: --screenshots
Specify directory where to write screenshots when an HttpCase.browser_js test
fails. It defaults to :file:`/tmp/odoo_tests/{db_name}/screenshots`
.. option:: --screencasts
Enable screencasts and specify directory where to write screencasts files.
The ``ffmpeg`` utility needs to be installed to encode frames into a video
file. Otherwise frames will be kept instead of the video file.
.. _reference/cmdline/server/database:
Database
--------
.. option:: -r <user>, --db_user <user>
database username, used to connect to PostgreSQL.
.. option:: -w <password>, --db_password <password>
database password, if using `password authentication`_.
.. option:: --db_host <hostname>
host for the database server
* ``localhost`` on Windows
* UNIX socket otherwise
.. option:: --db_port <port>
port the database listens on, defaults to 5432
.. option:: --db_replica_host <hostname>
host for the replica database server, disabled when not set / empty
.. option:: --db_replica_port <port>
the port the replica database listens on, defaults to :option:`--db_port`
.. option:: --db-filter <filter>
hides databases that do not match ``<filter>`` for the Web UI. The filter is a
`regular expression`_, with the additions that:
- ``%h`` is replaced by the whole hostname the request is made on.
- ``%d`` is replaced by the subdomain the request is made on, with the
exception of ``www`` (so domain ``odoo.com`` and ``www.odoo.com`` both
match the database ``odoo``).
These operations are case sensitive. Add option ``(?i)`` to match all
databases (so domain ``odoo.com`` using ``(?i)%d`` matches the database
``Odoo``).
Since version 11, it's also possible to restrict access to a given database
listen by using the --database parameter and specifying a comma-separated
list of databases
When combining the two parameters, db-filter supersedes the comma-separated
database list for restricting database list, while the comma-separated list
is used for performing requested operations like upgrade of modules.
.. code-block:: bash
$ odoo-bin --db-filter ^11.*$
Restrict access to databases whose name starts with 11
.. code-block:: bash
$ odoo-bin --database 11firstdatabase,11seconddatabase
Restrict access to only two databases, 11firstdatabase and 11seconddatabase
.. code-block:: bash
$ odoo-bin --database 11firstdatabase,11seconddatabase -u base
Restrict access to only two databases, 11firstdatabase and 11seconddatabase,
and update base module on one database: 11firstdatabase.
If database 11seconddatabase doesn't exist, the database is created and base modules
is installed
.. code-block:: bash
$ odoo-bin --db-filter ^11.*$ --database 11firstdatabase,11seconddatabase -u base
Restrict access to databases whose name starts with 11,
and update base module on one database: 11firstdatabase.
If database 11seconddatabase doesn't exist, the database is created and base modules
is installed
.. warning:: This option does not affect cron workers, if no --database is given, cron workers will run on every available database
.. option:: --db-template <template>
when creating new databases from the database-management screens, use the
specified `template database`_. Defaults to ``template0``.
.. option:: --db-system <db>
specify the database for shared system operations like bus and maintenance.
Defaults to ``postgres``.
.. option:: --pg_path </path/to/postgresql/binaries>
Path to the PostgreSQL binaries that are used by the database manager to
dump and restore databases. You have to specify this option only if these
binaries are located in a non-standard directory.
.. option:: --no-database-list
Suppresses the ability to list databases available on the system
.. option:: --db_sslmode
Control the SSL security of the connection between Odoo and PostgreSQL.
Value should be one of 'disable', 'allow', 'prefer', 'require',
'verify-ca' or 'verify-full'
Default value is 'prefer'
.. option:: --unaccent
Try to enable the unaccent extension when creating new databases
.. _reference/cmdline/server/emails:
Emails
------
.. option:: --email-from <address>
Email address used as <FROM> when Odoo needs to send mails
.. option:: --from-filter <address or domain>
Define which email address the SMTP configuration will apply to. The field can be a domain name
or an entire email address, or it can remain empty. If the sender's email address does not
match this set filter, then the email will be encapsulated using a combination of the two
system parameters: ``mail.default.from`` and ``mail.catchall.domain``. For example, "Admin"
<admin\@example.com> => "Admin" <notifications\@mycompany.com>.
.. option:: --smtp <server>
Address of the SMTP server to connect to in order to send mails
.. option:: --smtp-port <port>
.. option:: --smtp-ssl
If set, odoo should use SSL/STARTSSL SMTP connections
.. option:: --smtp-user <name>
Username to connect to the SMTP server
.. option:: --smtp-password <password>
Password to connect to the SMTP server
.. option:: --smtp-ssl-certificate-filename <path/to/cert.pem>
An SSL certificate is to be used for authentication. If set, then `smtp-ssl-private-key` is
required.
.. option:: --smtp-ssl-private-key-filename <path/to/key.pem>
An SSL private key is used for authentication. If set, then `smtp-ssl-certificate` is required.
.. _reference/cmdline/server/internationalisation:
Internationalisation
--------------------
.. option:: --load-language <languages>
specifies the languages (separated by commas) for the translations you
want to be loaded
.. option:: --i18n-overwrite
overwrites existing translation terms on updating a module or importing
a CSV or a PO file.
.. _reference/cmdline/advanced:
Advanced Options
----------------
.. _reference/cmdline/dev:
Developer features
~~~~~~~~~~~~~~~~~~
.. option:: --dev <feature,feature,...,feature>
comma-separated list of features. For development purposes only. Do not use it in production.
Possible features are:
* ``all``: alias for xml,reload,qweb,access
* ``xml``: read QWeb template from xml file directly instead of database.
Once a template has been modified in database, it will be not be read from
the xml file until the next update/init. Particularly, templates are not
translated on using this option.
* ``reload``: restart server when python file are updated (may not be detected
depending on the text editor used)
* ``qweb``: break in the evaluation of QWeb template when a node contains ``t-debug='debugger'``
* ``werkzeug``: display the full traceback on the frontend page in case of exception
* ``replica``: simulate :option:`--db_replica_host` but connect to the same datbase server as
:option:`--db_host`, this makes it possible to test read-only features without the need to set
up a replicated database.
* ``access``: log the traceback next to the AccessError when it results in a 403 - Forbidden
HTTP response.
.. _reference/cmdline/server/http:
HTTP
~~~~
.. option:: --no-http
do not start the HTTP or long-polling workers (may still start :ref:`cron <reference/actions/cron>`
workers)
.. warning:: has no effect if :option:`--test-enable` is set, as tests
require an accessible HTTP server
.. option:: --http-interface <interface>
TCP/IP address on which the HTTP server listens, defaults to ``0.0.0.0``
(all addresses)
.. option:: -p <port>
.. option:: --http-port <port>
Port on which the HTTP server listens, defaults to 8069.
.. option:: --gevent-port <port>
TCP port for websocket connections in multiprocessing or gevent mode,
defaults to 8072. Not used in default (threaded) mode.
.. option:: --proxy-mode
enables the use of ``X-Forwarded-*`` headers through `Werkzeug's proxy
support`_.
It ignores all ``X-Forwarded-*`` headers in case ``X-Forwarded-Host`` is
missing from the request.
It always gets the real IP from the last entry of the ``X-Forwarded-For``
chain. Configure your web server accordingly using directives such as
nginx's `set_real_ip_from <https://nginx.org/en/docs/http/ngx_http_realip_module.html>`_
in case there are other trusted proxies along the chain that must be ignored.
``X-Forwarded-Proto`` and ``X-Forwarded-Host`` are used to update the
request root URL, which in turn is used to update the ``web.base.url``
system parameter upon a successful admin authentication. This system
parameter is used to generate all links for the current database; see
:ref:`domain-name/web-base-url`.
.. warning:: proxy mode *must not* be enabled outside of a reverse proxy
scenario
.. option:: --x-sendfile
delegates serving attachments files to the static web server and sets both
``X-Sendfile`` (apache) and ``X-Accel-*`` (nginx) http headers on stream
responses. See :ref:`deploy/streaming` for web server configuration.
.. _reference/cmdline/server/logging:
Logging
~~~~~~~
By default, Odoo displays all logging of level_ ``INFO``, ``WARNING`` and ``ERROR``. All logs
independently of the level are output on ``stderr``. Various options are available to redirect
logging to other destinations and to customize the verbosity.
.. option:: --logfile <file>
sends logging output to the specified file instead of ``stderr``. On Unix, the
file `can be managed by external log rotation programs
<https://docs.python.org/3/library/logging.handlers.html#watchedfilehandler>`_
and will automatically be reopened when replaced
.. option:: --syslog
logs to the system's event logger: `syslog on unices <https://docs.python.org/3/library/logging.handlers.html#sysloghandler>`_
and `the Event Log on Windows <https://docs.python.org/3/library/logging.handlers.html#nteventloghandler>`_.
Neither is configurable
.. option:: --log-db <dbname>
logs to the ``ir.logging`` model (``ir_logging`` table) of the specified
database. The database can be the name of a database in the "current"
PostgreSQL, or `a PostgreSQL URI`_ for e.g. log aggregation.
.. option:: --log-handler <handler-spec>
:samp:`{LOGGER}:{LEVEL}`, enables ``LOGGER`` at the provided ``LEVEL``
e.g. ``odoo.models:DEBUG`` will enable all logging messages at or above
``DEBUG`` level in the models.
* The colon ``:`` is mandatory
* The logger can be omitted to configure the root (default) handler
* If the level is omitted, the logger is set to ``INFO``
The option can be repeated to configure multiple loggers e.g.
.. code-block:: console
$ odoo-bin --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler odoo.fields:WARNING
.. option:: --log-web
enables DEBUG logging of HTTP requests and responses, equivalent to
``--log-handler=odoo.http:DEBUG``
.. option:: --log-sql
enables DEBUG logging of SQL querying, equivalent to
``--log-handler=odoo.sql_db:DEBUG``
.. option:: --log-level <level>
Shortcut to more easily set predefined levels on specific loggers. "real"
levels (``critical``, ``error``, ``warn``, ``debug``) are set on the
``odoo`` and ``werkzeug`` loggers (except for ``debug`` which is only
set on ``odoo``).
Odoo also provides debugging pseudo-levels which apply to different sets
of loggers:
``debug_sql``
sets the SQL logger to ``debug``
equivalent to ``--log-sql``
``debug_rpc``
sets the ``odoo`` and HTTP request loggers to ``debug``
equivalent to ``--log-level debug --log-request``
``debug_rpc_answer``
sets the ``odoo`` and HTTP request and response loggers to
``debug``
equivalent to ``--log-level debug --log-request --log-response``
.. note::
In case of conflict between :option:`--log-level` and
:option:`--log-handler`, the latter is used
.. _reference/cdmline/workers:
Multiprocessing
~~~~~~~~~~~~~~~
.. option:: --workers <count>
if ``count`` is not 0 (the default), enables multiprocessing and sets up
the specified number of HTTP workers (sub-processes processing HTTP
and RPC requests).
.. note:: multiprocessing mode is only available on Unix-based systems
A number of options allow limiting and recycling workers:
.. option:: --limit-request <limit>
Number of requests a worker will process before being recycled and
restarted.
Defaults to *8196*.
.. option:: --limit-memory-soft <limit>
Maximum allowed virtual memory per worker in bytes. If the limit is exceeded,
the worker is killed and recycled at the end of the current request.
Defaults to *2048MiB (2048\*1024\*1024B)*.
.. option:: --limit-memory-hard <limit>
Hard limit on virtual memory in bytes, any worker exceeding the limit will be
immediately killed without waiting for the end of the current request
processing.
Defaults to *2560MiB (2560\*1024\*1024B)*.
.. option:: --limit-time-cpu <limit>
Prevents the worker from using more than <limit> CPU seconds for each
request. If the limit is exceeded, the worker is killed.
Defaults to *60*.
.. option:: --limit-time-real <limit>
Prevents the worker from taking longer than <limit> seconds to process
a request. If the limit is exceeded, the worker is killed.
Differs from :option:`--limit-time-cpu` in that this is a "wall time"
limit including e.g. SQL queries.
Defaults to *120*.
.. option:: --max-cron-threads <count>
number of workers dedicated to :ref:`cron <reference/actions/cron>` jobs. Defaults to *2*.
The workers are threads in multi-threading mode and processes in multi-processing mode.
For multi-processing mode, this is in addition to the HTTP worker processes.
.. option:: --limit-time-worker-cron <limit>
Soft limit on how long a :ref:`cron <reference/actions/cron>` thread/worker is
allowed to live before is is restarted, in seconds.
Set to 0 to disable.
Defaults to *0*.
.. _reference/cmdline/config:
Configuration file
==================
.. program:: odoo-bin
Most of the command-line options can also be specified via a configuration
file. Most of the time, they use similar names with the prefix ``-`` removed
and other ``-`` are replaced by ``_`` e.g. :option:`--db-template` becomes
``db_template``.
Some conversions don't match the pattern:
* :option:`--db-filter` becomes ``dbfilter``
* :option:`--no-http` corresponds to the ``http_enable`` boolean
* logging presets (all options starting with ``--log-`` except for
:option:`--log-handler` and :option:`--log-db`) just add content to
``log_handler``, use that directly in the configuration file
* :option:`--smtp` is stored as ``smtp_server``
* :option:`--database` is stored as ``db_name``
.. _reference/cmdline/config_file:
The default configuration file is :file:`{$HOME}/.odoorc` which
can be overridden using :option:`--config <odoo-bin -c>`. Specifying
:option:`--save <odoo-bin -s>` 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]``.
Here is a sample file:
.. code-block:: ini
[options]
db_user=odoo
dbfilter=odoo
.. _jinja2: https://jinja.palletsprojects.com/
.. _regular expression: https://docs.python.org/3/library/re.html
.. _password authentication:
https://www.postgresql.org/docs/12/static/auth-methods.html#AUTH-PASSWORD
.. _template database:
https://www.postgresql.org/docs/12/static/manage-ag-templatedbs.html
.. _level:
https://docs.python.org/3/library/logging.html#logging.Logger.setLevel
.. _a PostgreSQL URI:
https://www.postgresql.org/docs/12/static/libpq-connect.html#AEN38208
.. _Werkzeug's proxy support:
https://werkzeug.palletsprojects.com/en/0.16.x/middleware/proxy_fix/#module-werkzeug.middleware.proxy_fix
.. _pyinotify: https://github.com/seb-m/pyinotify/wiki
.. _reference/cmdline/shell:
`shell` - Open a Shell
======================
The Odoo command line also allows launching Odoo as a Python console environment, enabling direct
interaction with the :ref:`orm <reference/orm>` and its functionalities. Since running a shell
involves starting the server, the configuration file options do apply.
.. code-block:: console
$ odoo-bin shell
.. example::
Adding an exclamation mark to all contacts' names:
.. code-block:: python
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::
By default, the shell is running in transaction mode. This means that any change made to the
database is rolled back when exiting the shell. To commit changes, use `env.cr.commit()`.
.. option:: --shell-file <init_script.py>
Specify a Python script to be run after the start of the shell. Overrides the environment
variable `PYTHONSTARTUP`.
.. option:: --shell-interface (ipython|ptpython|bpython|python)
Specify a preferred `REPL` to use in shell mode. This shell is started with the `env` variable
already initialized to be able to access the `ORM` and other Odoo modules.
.. seealso::
:ref:`reference/orm/environment`
.. _reference/cmdline/db:
`db` - Manage a Database
========================
.. program:: odoo-bin db
This command lets you manage databases through a command-line interface. The operations are
specified using subcommands.
For all subcommands, these options to configure your environment are available:
- :option:`--addons-path <odoo-bin --addons-path>`
- :option:`--config <odoo-bin -c>`
- :option:`--data-dir <odoo-bin -d>`
- :option:`--db_user <odoo-bin --db_user>`
- :option:`--db_password <odoo-bin --db_password>`
- :option:`--db_host <odoo-bin --db_host>`
- :option:`--db_port <odoo-bin --db_port>`
- :option:`--db_sslmode <odoo-bin --db_sslmode>`
- :option:`--pg_path <odoo-bin --pg_path>`
.. _reference/cmdline/db/init:
`db init` - Initialize a Database
---------------------------------
.. program:: odoo-bin db init
This command creates a new database and installs the `base` module. You can specify the
language and country of the main company.
.. code-block:: console
$ odoo-bin db init <database>
.. option:: database
Name of the database to be initialized.
.. option:: --with-demo
Install demo data in the initialized database.
.. option:: --force
Delete the database if it already exists, before initializing the new one.
.. option:: --country <country_iso_code>
Code of the country to be set on the main company
.. option:: --language <language_code>
Default language for the instance, default `en_US`
.. option:: --username <password>
Username for the new database, default `admin`
.. option:: --password <password>
Password for the new database, default `admin`
.. _reference/cmdline/db/dump:
`db dump` - Save a Database Dump
--------------------------------
.. program:: odoo-bin db dump
Creates a dump file.
.. code-block:: console
$ odoo-bin db dump <database> <dump_path>
.. option:: database
Name of the database to dump.
.. option:: dump_path
(Optional) Database is dumped to specified path. By default it is dumped
to `stdout`.
.. option:: --format <zip | dump>
If provided, database is dumped used the specified format.
Supported formats are `zip` (default), `dump` (pg_dump format).
.. option:: --no-filestore
If provided, zip database is dumped without filestore
.. _reference/cmdline/db/load:
`db load` - Load a Database Dump
--------------------------------
.. program:: odoo-bin db load
Loads a dump file into an Odoo database, the dump file can be a URL.
.. code-block:: console
$ odoo-bin db load <database> <dump_file>
.. option:: database
(Optional) Name of the database to create from the dump.
If not provided, the dump filename without extension is used.
.. option:: dump_file
`.zip` or `pg_dump` file to be loaded.
.. option:: -f,--force
Delete the database if it already exists, before loading the new one.
.. option:: -n,--neutralize
Neutralize the database after restoring it.
.. _reference/cmdline/db/duplicate:
`db duplicate` - Duplicate a Database
-------------------------------------
.. program:: odoo-bin db duplicate
Duplicate a database including filestore.
.. code-block:: console
$ odoo-bin db duplicate <source> <target>
.. option:: source
Name of the source database.
.. option:: target
Name of the target database.
.. option:: -n,--neutralize
Neutralize the database, after restoring it.
.. option:: -f,--force
Delete the target database if it already exists, before initializing the new one.
.. _reference/cmdline/db/rename:
`db rename` - Rename a Database
-------------------------------
.. program:: odoo-bin db rename
Rename a database from an old name to a new one.
.. code-block:: console
$ odoo-bin db rename <source> <target>
.. option:: source
Current name of the database.
.. option:: target
New name for the database.
.. option:: -f,--force
Delete the target database if it already exists, before renaming the source one.
.. _reference/cmdline/db/drop:
`db drop` - Delete a Database
-----------------------------
.. code-block:: console
$ odoo-bin db drop <database>
.. program:: odoo-bin db drop
.. option:: database
Name of the database to drop.
.. _reference/cmdline/i18n:
`i18n` - Internationalization
=============================
.. program:: odoo-bin i18n
This command has subcommands that enable you to import or export internationalization files
and setup languages on the Odoo instance.
For all subcommands, these options to configure your environment are available:
- :option:`--addons-path <odoo-bin --addons-path>`
- :option:`--config <odoo-bin -c>`
- :option:`--database <odoo-bin --database>`
.. note::
Language codes must follow the XPG (POSIX) locale format.
To list available codes, you can search them querying the database:
.. code-block:: console
$ psql -d <dbname> -c "SELECT iso_code FROM res_lang ORDER BY iso_code"
.. seealso::
`GNU libc Locale Names <https://www.gnu.org/software/libc/manual/html_node/Locale-Names.html>`_
.. example::
.. code-block:: console
$ odoo-bin i18n loadlang -l en # English (U.S.)
$ odoo-bin i18n loadlang -l es es_AR # Spanish (Spain, Argentina)
$ odoo-bin i18n loadlang -l sr@latin # Serbian (Latin)
.. _reference/cmdline/i18n/import:
`i18n import` - Import i18n files
---------------------------------
.. program:: odoo-bin i18n import
This command imports provided translation files in the `.po` or `.csv` formats.
By default, only new entries will be added, but you can choose to overwrite
existing terms. All the files must refer to the specified language.
.. code-block:: console
$ odoo-bin i18n import <files> --overwrite --language <language_code>
.. option:: files
| List of files to be imported.
| Allowed extensions: `.po`, `.csv`.
.. option:: -l,--language
(Required) Language code of the translations in the files.
.. option:: -w,--overwrite
Overwrite existing translation when importing.
.. _reference/cmdline/i18n/export:
`i18n export` - Export i18n files
---------------------------------
.. program:: odoo-bin i18n export
This command exports existing translation terms for modules in the Odoo database
to a range of formats: `.po`, `.pot`, `.tgz`, `.csv`. In case of `.po` and `.pot`
files, they will be created under the `i18n/` folder of the module they belong to.
If you specify an output parameter, only one language can be selected, and all
the output will refer to that language.
The `.tgz` output format makes all output be archived in a single file.
.. code-block:: console
$ odoo-bin i18n export <modules> --languages <language_codes>
.. option:: modules
List of modules you want to export the internationalization files from.
.. option:: -l,--languages <languages>
List of language codes you want to export, `pot` for template (default).
.. option:: -o,--output
| Path of an only output file with translations from all provided modules.
| Allowed extensions: `.po`, `.pot`, `.tgz`, `.csv`
| If `-` is provided, the content is written as a `.po` file to stdout.
Only one language is allowed when this option is active.
.. _reference/cmdline/i18n/loadlang:
`i18n loadlang` - Load language
-------------------------------
.. program:: odoo-bin i18n loadlang
This command loads one of the available languages into the Odoo database and activates it.
.. code-block:: console
$ odoo-bin i18n loadlang <languages>
.. option:: languages
language codes of the languages to be installed.
.. _reference/cmdline/module:
`module` - Manage modules
=========================
.. program:: odoo-bin module
This command has subcommands that enable you to install, uninstall and upgrade modules
on the Odoo instance. There's also a command to force install the demo data into the
database.
For all subcommands, these options are available:
- :option:`--addons-path <odoo-bin --addons-path>`
- :option:`--config <odoo-bin -c>`
- :option:`--database <odoo-bin --database>`
.. _reference/cmdline/module/install:
`module install` - Install modules
----------------------------------
.. program:: odoo-bin module install
This command installs all selected modules straight away.
Before installing modules, the Odoo database needs to be created and initialized
on your PostgreSQL instance, e.g. using the :ref:`reference/cmdline/db/init` command.
.. code-block:: console
$ odoo-bin module install <modules>
.. option:: modules
List of modules you want to install.
.. _reference/cmdline/module/uninstall:
`module uninstall` - Uninstall modules
--------------------------------------
.. program:: odoo-bin module uninstall
This command uninstalls all selected modules straight away.
.. code-block:: console
$ odoo-bin module uninstall <modules>
.. option:: modules
List of modules you want to uninstall.
.. _reference/cmdline/module/upgrade:
`module upgrade` - Upgrade modules
----------------------------------
.. program:: odoo-bin module upgrade
This command upgrades all selected modules straight away.
.. code-block:: console
$ odoo-bin module upgrade <modules>
.. option:: modules
List of modules you want to upgrade.
.. option:: --outdated
Only update modules that have a newer version on disk.
.. _reference/cmdline/module`u/forcedemo:
`module forcedemo` - Force demo data install
--------------------------------------------
.. program:: odoo-bin module forcedemo
This command forces the installation of :ref:`Demo Data <tutorials/define_module_data/demo_data>`
.. warning::
Once installed, there is no way to undo it, so you might want to save a backup of the database
first with the command :ref:`db dump <reference/cmdline/db/dump>`
There are no additional options to this command.
.. _reference/cmdline/neutralize:
`neutralize` - Neutralize a Database
====================================
.. program:: odoo-bin neutralize
The Odoo command line allows for neutralizing a database as well. The command must be run with a
database option.
.. code-block:: console
$ odoo-bin --addons-path <PATH,...> neutralize -d <database>
.. option:: -d <database>, --database <database>
Specify the database name that you would like to neutralize.
.. option:: --stdout
Output the neutralization SQL instead of applying it
.. seealso::
:doc:`../../administration/neutralized_database`
.. _reference/cmdline/scaffold:
`scaffold` - Scaffold a Module
==============================
.. program:: odoo-bin scaffold
Scaffolding is the automated creation of a skeleton structure to simplify
bootstrapping (of new modules, in the case of Odoo). While not necessary it
avoids the tedium of setting up basic structures and looking up what all
starting requirements are.
Scaffolding is available via the :command:`odoo-bin scaffold` subcommand.
.. code-block:: console
$ odoo-bin scaffold my_module /addons/
.. option:: name (required)
the name of the module to create, may munged in various manners to
generate programmatic names (e.g. module directory name, model names, …)
.. option:: destination (default=current directory)
directory in which to create the new module, defaults to the current
directory
.. option:: -t <template>
a template directory, files are passed through jinja2_ then copied to
the ``destination`` directory
This will create module *my_module* in directory */addons/*.
.. _reference/cmdline/populate:
`populate` - Populate a Database
================================
.. program:: odoo-bin populate
Odoo Populate allows to duplicate existing data in a given database. This can be used
for testing and benchmarking when large tables are needed. The duplication process
introduces variation for some fields to respect `UNIQUE` constraints, among other things.
It also follows x2Many relationships.
.. code-block:: console
$ odoo-bin populate -d my_database --models res.partner,account.move --factors 1000
.. option:: -d <database>
name of the database to populate
.. option:: --models <models>
list of models to populate. Models appearing twice will only be populated once.
.. option:: --factors <factors>
list of populate factors. In case a factor is missing for a model, the last factor in
the list will be used.
.. option:: --sep <separator>
separator used to generate record names
.. _reference/cmdline/cloc:
`cloc` - Count Lines of Code
============================
.. program:: odoo-bin cloc
Odoo Cloc is a tool to count the number of relevant lines of code written in
Python, Javascript, CSS, SCSS, or XML. This can be used as a rough metric for pricing
maintenance of extra modules.
.. code-block:: console
$ odoo-bin cloc -c config.conf -d my_database
.. option:: -d <database>, --database <database>
| Process the code of all extra modules installed on the provided database,
and of all server actions and computed fields manually created in the provided
database.
| The :option:`--addons-path` option is required to specify the path(s) to the
module folder(s).
| If combined with :option:`--path`, the count will be that of the sum of both
options' results (with possible overlaps). At least one of these two options is
required to specify which code to process.
.. code-block:: console
$ odoo-bin cloc --addons-path=addons -d my_database
.. seealso::
- :ref:`reference/cmdline/cloc/database-option`
.. option:: -p <path>, --path <path>
| Process the files in the provided path.
| If combined with :option:`--database`, the count will be that of the sum of both
options' results (with possible overlaps). At least one of these two options is
required to specify which code to process.
.. code-block:: console
$ odoo-bin cloc -p addons/account
Multiple paths can be provided by repeating the option.
.. code-block:: console
$ odoo-bin cloc -p addons/account -p addons/sale
.. seealso::
- :ref:`reference/cmdline/cloc/path-option`
.. option:: --addons-path <directories>
| Comma-separated list of directories in which modules are stored. These directories
are scanned for modules.
| Required if the :option:`--database` option is used.
.. option:: -c <directories>
Specify a configuration file to use in place of the :option:`--addons-path` option.
.. option:: -v, --verbose
Show the details of lines counted for each file.
Processed files
---------------
.. _reference/cmdline/cloc/database-option:
With the :option:`--database` option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Odoo Cloc counts the lines in each file of extra installed modules in a
given database. In addition, it counts the Python lines of server actions and
custom computed fields that have been directly created in the database or
imported. Finally, it counts the lines of code of Javascript, CSS, and SCSS files,
and of QWeb views from imported modules.
Some files are excluded from the count by default:
- The manifest (:file:`__manifest__.py` or :file:`__openerp__.py`)
- The contents of the folder :file:`static/lib`
- The tests defined in the folder :file:`tests` and :file:`static/tests`
- The migrations scripts defined in the folder :file:`migrations` and `upgrades`
- The XML files declared in the ``demo`` or ``demo_xml`` sections of the manifest
For special cases, a list of files that should be ignored by Odoo Cloc can be defined
per module. This is specified by the ``cloc_exclude`` entry of the manifest:
.. code-block:: python
"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
]
| The pattern ``**/*`` can be used to ignore an entire module. This can be useful
to exclude a module from maintenance service costs.
| For more information about the pattern syntax, see `glob
<https://docs.python.org/3/library/pathlib.html#pathlib.Path.glob>`_.
.. _reference/cmdline/cloc/path-option:
With the :option:`--path` option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This method works the same as with the :ref:`--database option
<reference/cmdline/cloc/database-option>` if a manifest file is present in the given
folder. Otherwise, it counts all files.
Identifying Extra Modules
-------------------------
To distinguish between standard and extra modules, Odoo Cloc uses the following heuristic:
modules that are located (real file system path, after following symbolic links)
in the same parent directory as the ``base``, ``web`` or ``web_enterprise``
standard modules are considered standard. Other modules are treated as extra modules.
Error Handling
--------------
Some file cannot be counted by Odoo Cloc.
Those file are reported at the end of the output.
Max file size exceeded
~~~~~~~~~~~~~~~~~~~~~~
Odoo Cloc rejects any file larger than 25MB. Usually, source files are smaller
than 1 MB. If a file is rejected, it may be:
- A generated XML file that contains lots of data. It should be excluded in the manifest.
- A JavaScript library that should be placed in the :file:`static/lib` folder.
Syntax Error
~~~~~~~~~~~~
Odoo Cloc cannot count the lines of code of a Python file with a syntax problem.
If an extra module contains such files, they should be fixed to allow the module to
load. If the module works despite the presence of those files, they are probably
not loaded and should therefore be removed from the module, or at least excluded
in the manifest via ``cloc_exclude``.
.. _reference/cmdline/obfuscate:
`obfuscate` - Obfuscate database
================================
.. program:: odoo-bin obfuscate
This command provides a quick and easy way to obfuscate some of the data in the
Odoo instance, mainly used for instructional purposes or to make quick videos for
the support team helping technicians avoid leaking sensitive information.
.. warning::
This command must be used carefully, as it is **not** considered a safe method
for full anonymizing data before transfer to a third party. Images, PDF
attachments, amounts, many other informations may not be obfuscated and cause
sensitive information leaks. A thorough review is required before sharing data
to ensure that no sensitive information is exposed.
Obfuscation is symmetric, so content can be unobfuscated using the same password.
All the configurations available for the :ref:`server <reference/cmdline/server>`
command are available here too.
.. code-block:: console
$ odoo-bin obfuscate --pwd=<password>
.. option:: --pwd <password>
(Required) the password that will be used to symmetrically obfuscate content.
.. option:: --unobfuscate
if you want to unobfuscate instead of obfuscate.
.. option:: --fields <fields>
comma-separated list of `table.column` entries to obfuscate/unobfuscate.
.. option:: --file <file>
file containing the list of `table.column` entries to obfuscate/unobfuscate.
.. option:: --exclude
comma-separated list of `table.column` entries not to obfuscate/unobfuscate.
.. option:: --allfields
used only when :option:`--unobfuscate` is selected.
Try to unobfuscate all fields. It's slower than specifying the fields manually.
.. option:: --vacuum
used only when :option:`--unobfuscate` is selected.
After unobfuscation, completely clear the obfuscated tables and reclaim unused disk space.
.. option:: --pertablecommit
commit once per table, after obfuscation.
It avoids big transactions that might get a timeout or face rollback after an error.
.. option:: -y,--yes
don't ask for manual confirmation.
Only use if you're sure that you're not going to leak sensible information by sharing
the database to third party without a review.
.. _reference/cmdline/deploy:
`deploy` - Deploy module remotely
=================================
.. program:: odoo-bin deploy
This command uploads a module to a remote Odoo server and installs it.
It's simpler than manually connecting to the remote server, and it does not require full access
to the machine that hosts the Odoo instance, only the Odoo administrative credentials.
.. code-block:: console
$ odoo-bin deploy <path> <url> --db <dbname> --login <login> --password <password>
.. note::
Prerequisites:
- The server must have the module `base_import_module` installed.
- The user selected with the `--login` option must have administrative rights.
.. option:: path
path of the module to be deployed
.. option:: url
(Optional) url of the server where the module must be deployed
(default `http://localhost:8069`)
.. option:: db <dbname>
database name (if the server does not use the `--db-filter` option)
.. option:: --login <username>
name of the user with admin rights (default `admin`)
.. option:: --password <password>
password of the user with admin rights (default `admin`)
.. option:: --verify-ssl
verify the server's SSL certificate, to ensure the target instance is legit.
.. option:: --force
re-initialize the module in case it's already installed. It will update
`noupdate="1"` records.
.. _reference/cmdline/upgrade_code:
`upgrade_code` - Rewrite source code
====================================
.. program:: odoo-bin upgrade_code
This command rewrites the entire source code using the scripts found in the
`odoo/upgrade_code` folder. It is used for doing the heavy-lifting when
dealing with big code migrations and forward ports.
.. note::
All the scripts are doing a best-effort at migrating the source code, but
they are not silver bullets.
It accepts the :option:`--addons-path <odoo-bin --addons-path>` option.
.. code-block:: console
$ odoo-bin upgrade_code --from 18.0 --to 19.0 --dry-run
.. option:: --script <path>
run a single script
.. option:: --from <version>
run all script starting from this version included
.. option:: --to <version>
to be used with :option:`--from`. Run all scripts up to this version included.
Default is `odoo.release.version`.
.. option:: --glob <glob>
filter the files to be rewritten, default is every file (`\*\*/\*`)
.. option:: --dry-run
list the files that would be re-written, but do not apply changes
Code upgrade scripts
--------------------
The scripts must be named `{version}-{name}.py`, and must expose an `upgrade`
function that takes a single `file_manager` argument and have no return.
The `file_manager` argument is a sequence of `files`, which have 3 attributes
and some helper methods:
- `path`: the `pathlib.Path` where the file is on the file system.
- `addon`: the addon the file belongs to.
- `content`: the re-writtable content of the file (lazy).
- `print_progress(current, total)`: outputs the current progress.
.. example::
.. code-block:: python
def upgrade(file_manager):
files = (file for file in file_manager if file.path.suffix == '.py')
for fileno, file in enumerate(files, start=1):
file.content = file.content.replace(..., ...)
file_manager.print_progress(fileno, len(files))