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

You 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, by using a --template option.

Make sure your Odoo instance is stopped and you have no other connection open on the v8dev database created above, and run:

$ createdb --template=v8dev v8test

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 utility psql utility with the -l option:

$ psql -l

Running it we should see listed the two databases we created so far: v8dev and v8test. The list will also display the encoding used in each database. The default is UTF8, which is the encoding needed for Odoo databases.

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

$ dropdb v8test

Now you know the basics to work with several databases. To learn more on PostgresSQL, the official documentation can be found at http://www.postgresql.org/docs/

Most of the options can be saved in a configuration file. By default, Odoo will use the .openerp-serverrc file in your home directory. Conveniently, there is also the --save option to store the current instance configuration into that file:

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

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

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

$ more ~/.openerp_serverrc  # show the configuration file

This will show all configuration options available with the default values for them. 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 the options you've just seen. Only the ones that actually change a default value need to be there.

The --xmlrpc-server=<port> command allows us to change the default 8069 port where the server instance listens. This can be used to run more than one instances at the same time, on the same server.

Let's try that. Open two terminal windows. On the first one run:

$ ~/odoo-dev/odoo.py --xmlrpc-port=8070

and on the other run:

$ ~/odoo-dev/odoo.py --xmlrpc-port=8071

And there you go: two Odoo instances on the same server listening on different ports. The two instances can use the same or different databases. And the two could be running the same or different versions of Odoo.

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

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 option --logfile=<filepath>.

Finally, the --debug 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 here: 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, then 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 project provides Linux file sharing services compatible with Microsoft Windows systems. We can install it on our Debian/Ubuntu server with:

$ 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 and set a password for its file share access:

$ sudo smbpasswd -a odoo

After this the odoo user will be able to access a fileshare for its home directory, but it will be read only. We want to have write access, so we need to edit Sambas, configuration file to change that:

$ 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 below:

[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 user and password defined with smbpasswd. When trying to log in with the odoo user, you might find trouble with Windows adding the computer's domain to the user name (for example MYPC\odoo). To avoid this, use an empty domain by prepending a \ 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 home directory.

Technical Features provide advanced server configuration tools.

They are disabled by default, and to enable them, we need to log in as admin. In the Settings menu, select Users and edit the Administrator user. In the Access Rights tab, you will find a Technical Features checkbox. Let's check it and save.

Now we need to reload the page in our web browser. Then we should see in the Settings menu a new Technical menu section giving access to many Odoo server internals.

The Technical menu option allows us to inspect and edit all Odoo configurations stored in the database, from user interface to security and other system parameters. You will be learning more about many of these throughout the book.

The Developer mode enables a combobox near the top of Odoo windows, making a few advanced configuration options available throughout the application. It also disables the minification of JavaScript and CSS used by the web client, making it easier to debug client-side behavior.

To enable it, open the drop-down menu from the top-right corner of the browser window, next to the username, and select the About Odoo option. In the About dialog, click on the Activate the developer mode button at the top-right corner.

After this, we will see a Debug View combo box at the top left of the current form area.

There are many Odoo modules available from the Internet. The apps.odoo.com website is a catalogue of modules that can be downloaded and installed in 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 addons.

As an example, we will download the OCA project department and make its modules available in our Odoo installation. This project is a set of very simple modules adding a Department field on several forms, such as Projects or CRM Opportunities.

To get the source code from GitHub:

$ cd ~/odoo-dev
$ git clone https://github.com/OCA/department.git -b 8.0

We used the optional -b option to make sure we are downloading the modules for the 8.0 version. Since at the moment of writing 8.0 is the projects default branch we could have omitted it.

After this, we will have a new /department 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 setting where to look for modules. By default this points at the /addons directory where the Odoo server is running.

Fortunately, we can provide Odoo 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 including our new module directory:

$ cd ~/odoo-dev/odoo
$ ./odoo.py -d v8dev --addons-path="../department,./addons"

If you look closer at the server log you will notice a line reporting the addons path in use: INFO ? openerp: addons paths: (...). Confirm that it contains our department directory.

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

For this we need the Technical menu enabled, since the Update Modules List menu option is provided by it. It can be found in the Modules section of the Settings menu.

After running the modules list update we can confirm the new modules are available to install. In the Local Modules list, remove the Apps filter and search for department. You should see the new modules available.