Book Image

Odoo 10 Development Essentials

By : Daniel Reis
Book Image

Odoo 10 Development Essentials

By: Daniel Reis

Overview of this book

Odoo is one of the fastest growing open source, business application development software products available. With announcement of Odoo 10, there are many new features added to Odoo and the face of business applications developed with Odoo has changed. This book will not only teach you how to build and customize business applications with Odoo, but it also covers all the new features that Odoo has to offer. This book is the latest resource on developing and customizing Odoo 10 applications. It comes packed with much more and refined content than its predecessor. It will start with building business applications from scratch and will cover topics such as module extensions, inheritance, working with data, user interfaces, and so on. The book also covers the latest features of Odoo 10, in addition to front end development, testing and debugging techniques. The book will also talk about Odoo Community and Odoo Enterprise.
Table of Contents (20 chapters)
Odoo 10 Development Essentials
Credits
Foreword
About the Author
About the Reviewer
www.PacktPub.com
Preface

More server configuration options


The Odoo server supports quite a few other options. We can check all the available options with --help:

$ ./odoo-bin --help

We will review some of the most important options in the following sections. Let's start by looking at how the currently active options can be saved in a configuration file.

Odoo server configuration files

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.

Note

In previous Odoo/OpenERP versions, the name for the default configuration file was .openerp-serverrc. For backward compatibility, Odoo 10 will still use this if it's present and no .odoorc file is found.

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.

Changing the listening port

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.

The database filter option

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$

Managing server log messages

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:

  • debug_sql to inspect SQL queries generated by the server
  • debug_rpc to detail the requests received by the server
  • debug_rpc_answer to detail the responses sent by the server

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 .