The odoo-bin script has dozens of options, and it is tedious to remember them, all as well as remembering to set them properly when starting the server. Fortunately, it is possible to store them all in a configuration file and to only specify by hand the ones you want to alter, for example, for development.
Storing the instance configuration in a file
How to do it...
To generate a configuration file for your Odoo instance, run the following command:
$ ./odoo-bin --save --config myodoo.cfg --stop-after-init
You can add additional options, and their values will be saved in the generated file. All of the unset options will be saved with their default value set. To get a list of possible options, use the following command:
$ ./odoo-bin --help | less
This will provide you with some help about what the various options perform. To convert from the command-line form into the configuration form, use the long option name, remove the leading dashes, and convert the dashes in the middle into underscores:
--without-demo then becomes without_demo. This works for most options, but there are a few exceptions, which are listed in the following section.
Edit the myodoo.cfg file (use the table in the following section for some parameters you may want to change). Then, to start the server with the saved options, run the following command:
$ ./odoo-bin -c myodoo.cfg
The --config option is commonly abbreviated as -c.
How it works...
At startup, Odoo loads its configuration in three passes. First, a set of default values for all options is initialized from the source code, then the configuration is parsed, and any value that's defined in the file overrides the defaults. Finally, the command-line options are analyzed and their values override the configuration that was obtained from the previous pass.
As we mentioned earlier, the names of the configuration variables can be found from the names of the command-line options by removing the leading dashes and converting the middle dashes into underscores. There are a few exceptions to this, notably the following:
|
Command line |
Configuration file |
|
--db-filter |
dbfilter |
|
--no-http |
http_enable = True/False |
|
--database |
db_name |
|
--dev |
dev_mode |
|
--i18n-import/--i18n-export |
Unavailable |
Here's a list of options that are commonly set through the configuration file:
|
Option |
Format |
Usage |
|
without_demo |
Comma-separated list of module names, or all (to disable demo data for all modules), or False (to enable demo data for all modules) |
This prevents module demo data from being loaded. |
|
addons_path |
Comma-separated list of paths |
This is a list of directory names in which the server will look for add-ons (refer to Chapter 2, Managing Odoo Server Instances). |
|
admin_passwd |
Text |
This is the master password (take a look at the preceding recipe). |
|
data_dir |
Path to a directory |
This is a directory in which the server will store session information, add-ons downloaded from the internet, and documents if you enable the file store. |
|
db_host |
Hostname |
This is the name of the server running the PostgreSQL server. Use False to use local Unix Domain sockets, and localhost to use TCP sockets locally. |
|
db_user |
Database user login |
This is generally empty if db_host is False. This will be the name of the user used for connecting database. |
|
db_password |
Database user password |
This is generally empty if db_host is False and when db_user has the same name as the user running the server. Read the main page of pg_hba.conf for more information on this. |
|
db_name |
Database name |
This is used to set the database name on which some commands operate by default. This does not limit the databases on which the server will act. Refer to the following dbfilter option for this. |
|
dbfilter |
A regular expression |
The expression should match the name of the databases that are considered by the server. If you run the website, it should match a single database, so it will look like ^databasename$. More information on this can be found in Chapter 3, Server Deployment. |
|
http_interface |
IP address of a network interface |
This defaults to 0.0.0.0, which means that the server listens on all interfaces. |
|
http_port longpolling_port |
Port number |
These are the ports on which the Odoo server will listen. You will need to specify both to run multiple Odoo servers on the same host; longpolling_port is only used if workers is not 0. http_port defaults to 8069 and longpolling_port default to 8072. |
|
logfile |
Path to a file |
The file in which Odoo will write its logs. |
|
log_level |
Log verbosity level |
Specifies the level of logging. Accepted values (in increasing verbosity order) include critical, error, warn, info, debug, debug_rpc, debug_rpc_answer, debug_sql. |
|
workers |
Integer |
The number of worker processes. Refer to Chapter 3, Server Deployment, for more information. |
|
list_db |
True/False |
Set to True to disable listing of databases. See Chapter 3, Server Deployment, for more information. |
|
proxy_mode |
True/False |
Activate reverse proxy WSGI wrappers. Only enable this when running behind a trusted web proxy! |
The parsing of the configuration file by Odoo is now using the Python ConfigParser module. However, the implementation in Odoo 11.0 has changed, and it is no longer possible to use variable interpolation. So, if you are used to defining values for variables from the values of other variables using the %(section.variable)s notation, you will need to change your habits and revert to explicit values.
Some options are not used in config files, but they are widely used during development:
|
Options |
Format |
Usage
|
|
-i or --init |
Comma-separated list of module names |
It will install given modules by default while initializing the database. |
|
-u or --update |
Comma-separated list of module names |
It will update given modules when you restart the server. It is mostly used when you modify source code or update the branch from git. |
|
--dev |
all, reload, qweb, werkzeug, xml
|
This enables developer mode and the auto-reload feature.
|