We've seen how to create and initialize new Odoo databases from the command line. There are more commands worth knowing for managing databases.

We already know how to use the createdb command to create empty databases, but it can also create a new database by copying an existing one, using the --template option.

Make sure your Odoo instance is stopped and you have no other connection open on the demo database we just created, then run this:

$ createdb --template=demo demo-test

In fact, every time we create a database, a template is used. If none is specified, a predefined one called template1 is used.

To list the existing databases in your system, use the PostgreSQL psql utility with the -l option:

$ psql -l

Running it will list the two databases we have created so far: demo and demo-test. The list will also display the encoding used in each database. The default is UTF-8, which is the encoding needed for Odoo databases.

To remove a database you no longer need (or want to recreate) to use the dropdb command:

$ dropdb demo-test

Now you know the basics to work with databases. To learn more about PostgreSQL, refer to the official documentation at http://www.postgresql.org/docs/ .

Most of the options can be saved in a configuration file. By default, Odoo will use the .odoorc file in your home directory. In Linux systems its default location is in the home directory ($HOME), and in the Windows distribution it is in the same directory as the executable used to launch Odoo.

On a clean install, the .odoorc configuration file is not automatically created. We should use the --save option to create the default configuration file, if it doesn't exist yet, and store the current instance configuration into it:

$ ~/odoo-dev/odoo/odoo-bin --save --stop-after-init  #save configuration to file

Here, we also used the --stop-after-init option to stop the server after it finishes its actions. This option is often used when running tests or asking to run a module upgrade to check whether it is installed correctly.

Now we can inspect what was saved in this default configuration file:

$ more ~/.odoorc  # show the configuration file

This will show all the configuration options available with their default values. Editing them will be effective the next time you start an Odoo instance. Type q to quit and go back to the prompt.

We can also choose to use a specific configuration file, using the --conf=<filepath> option. Configuration files don't need to have all those options you've just seen. Only the ones that actually change a default value need to be there.

The --xmlrpc-port=<port> command option allows us to change the listening port of a server instance from the default 8069. This can be used to run more than one instance at the same time, on the same machine.

Let's try this out. Open two terminal windows. On the first, run this:

$ ~/odoo-dev/odoo/odoo-bin --xmlrpc-port=8070

Run the following command on the second terminal:

$ ~/odoo-dev/odoo/odoo-bin --xmlrpc-port=8071

There you go: two Odoo instances on the same server listening on different ports! The two instances can use the same or different databases, depending on the configuration parameters used. And the two could be running the same or different versions of Odoo.

When developing with Odoo, it is frequent to work with several databases, and sometimes even with different Odoo versions. Stopping and starting different server instances on the same port, and switching between different databases, can cause web client sessions to behave improperly.

Accessing our instance using a browser window running in private mode can help avoiding some of these problems.

Another good practice is to enable a database filter on the server instance to ensure that it only allows requests for the database we want to work with, ignoring all others. This is done with the --db-filter option. It accepts a regular expression to be used as a filter for the valid database names. To match an exact name, the expression should begin with a ^ and end with $.

For example, to allow only the demo database we would use this command:

$ ~/odoo-dev/odoo/odoo-bin --db-filter=^demo$

The --log-level option allows us to set the log verbosity. This can be very useful to understand what is going on in the server. For example, to enable the debug log level, use  --log-level=debug option.

The following log levels can be particularly interesting:

By default, the log output is directed to standard output (your console screen), but it can be directed to a log file with the --logfile=<filepath> option.

Finally, the --dev=all option will bring up the Python debugger (pdb) when an exception is raised. It's useful to do a post-mortem analysis of a server error. Note that it doesn't have any effect on the logger verbosity. More details on the Python debugger commands can be found at https://docs.python.org/2/library/pdb.html#debugger-commands .

Sooner or later, we will need to edit files from the shell command line. In many Debian systems, the default text editor is vi. If you're not comfortable with it, you probably could use a friendlier alternative. In Ubuntu systems, the default text editor is nano. You might prefer it since it's easier to use. In case it's not available in your server, it can be installed with:

$ sudo apt-get install nano

In the following sections, we will assume nano as the preferred editor. If you prefer any other editor, feel free to adapt the commands accordingly.

The Samba service helps make Linux file-sharing services compatible with Microsoft Windows systems. We can install it on our Debian/Ubuntu server with this command:

$ sudo apt-get install samba samba-common-bin

The samba package installs the file-sharing services, and the samba-common-bin package is needed for the smbpasswd tool. By default, users allowed to access shared files need to be registered with it. We need to register our user, odoo for example, and set a password for its file share access:

$ sudo smbpasswd -a odoo

After this, we will be asked for a password to use to access the shared directory, and the odoo user will be able to access shared files for its home directory, although it will be read only. We want to have write access, so we need to edit the Samba configuration file to change it as follows:

$ sudo nano /etc/samba/smb.conf

In the configuration file, look for the [homes] section. Edit its configuration lines so that they match the settings as follows:

[homes] 
    comment = Home Directories 
    browseable = yes 
    read only = no 
    create mask = 0640 
    directory mask = 0750 

For the configuration changes to take effect, restart the service:

$ sudo /etc/init.d/smbd restart

To access the files from Windows, we can map a network drive for the path \\<my-server-name>\odoo using the specific username and password defined with smbpasswd. When trying to log in with the odoo user, you might encounter trouble with Windows adding the computer's domain to the username (for example, MYPC\odoo). To avoid this, use an empty domain by prepending a \ character to the login (for example, \odoo):

If we now open the mapped drive with Windows Explorer, we will be able to access and edit the contents of the odoo user's home directory:

Odoo includes a couple of tools that are very helpful for developers, and we will make use of them throughout the book. They are technical features and the developer mode. These are disabled by default, so this is a good moment to learn how to enable them.

The developer tools provide advanced server configuration and features. These include a debug menu in the top menu bar along with additional menu options in the Settings menu, in particular the Technical menu.

These tools come disabled by default, and to enable them, we need to log in as admin. In the top menu bar, select the Settings menu. At the bottom-right, below the Odoo version, you will find two options to enable the developer mode; any of them will enable the Debug and Technical menus. The second option, Activate the developer mode (with assets), also disables the minification of JavaScript and CSS used by the web client, making it easier to debug client-side behavior:

After that, the page is reloaded and you should see a bug icon in the top menu bar, just before the session user avatar and name providing the debug mode options. And in the Settings option in the top menu, we should see a new Technical menu section giving access to many Odoo instance internals:

There are many Odoo modules available on the Internet. The Odoo apps store at apps.odoo.com is a catalogue of modules that can be downloaded and installed on your system. The Odoo Community Association (OCA) coordinates community contributions and maintains quite a few module repositories on GitHub at https://github.com/OCA/ .

To add a module to an Odoo installation, we could just copy it into the addons directory alongside the official modules. In our case, the addons directory is at ~/odoo-dev/odoo/addons/. This might not be the best option for us since our Odoo installation is based on a version-controlled code repository, and we will want to keep it synchronized with the GitHub repository.

Fortunately, we can use additional locations for modules so we can keep our custom modules in a different directory, without having them mixed with the official ones.

As an example, we will download the code from this book, available in GitHub, and make those addon modules available in our Odoo installation.

To get the source code from GitHub, run the following commands:

$ cd ~/odoo-dev
$ git clone https://github.com/dreispt/todo_app.git -b 10.0

We used the -b option to make sure we are downloading the modules for the 10.0 version.

After this, we will have a new /todo_app directory alongside the /odoo directory, containing the modules. Now we need to let Odoo know about this new module directory.

The Odoo server has a configuration option called addons_path to set where the server should look for modules. By default, this points to the /addons directory, where the Odoo server is running.

We can provide not only one, but a list of directories where modules can be found. This allows us to keep our custom modules in a different directory, without having them mixed with the official addons.

Let's start the server with an addons path that includes our new module directory:

$ cd ~/odoo-dev/odoo
$ ./odoo-bin -d demo --addons-path="../todo_app,./addons"

If you look closer at the server log, you will notice a line reporting the addons path in use: INFO? odoo: addons paths: [...]. Confirm that it contains our todo_app directory.

We still need to ask Odoo to update its module list before these new modules are made available for installation.

For this, we need developer mode enabled, since it provides the Update Apps List menu option. It can be found in the Apps top menu.

After updating the modules list, we can confirm the new modules are available for installation. Use the Apps menu option to see the list of local modules. Search for todo and you should see the new modules made available.

Note that the second App Store menu option displays the module list from Odoo apps store instead of your local modules: