Odoo Development Essentials

[Sabel Kantah]

Odooprovides a rapid application development framework that is particularly suited to building applications for business. Business applications usually focus on keeping business records and workflows. Odoo makes it easy to build this type of application and provides rich components to create compelling user interfaces (UIs), such as a kanban view, as well as calendar and graph views.

The minimum requirement for this chapter is to have a modern web browser, such as Mozilla Firefox or Google Chrome. With a browser and an internet connection, you can follow the chapter using an Odoo SaaS trial database, and no local installation is needed.

Of course, you can use a locally installed instance of Odoo if you want. In this case, you can follow the instructions in the Installing Odoo in your workstation section, which describes prepackaged installations for Windows, Ubuntu, and Red Hat Enterprise Linux (RHEL). Alternatively, you can use Docker.

For the Data tier, we will create a To-do Item model. For the work team feature, we will make use of the built-in Contact model (also known as the Partner model). And we must not forget to configure the access control security for our new model.

The Business Logic tier will allow the basic create, read, update, and delete (CRUD) operations handled by the framework. In this case, we don't have additional automation requirements to support. We need to use Python code in developer modules to access the full power of the framework. We won't be doing that for developer modules yet, but the Technical menu provides access to the Automated Actions tool to implement business logic from the UI. We will look at an example of how to use this tool later in the chapter.

Finally, for the Presentation tier, we will add the menu option for our application and the views for the To-do Item model. The essential views for a business application are the list view (to browse the existing records) and the form view (to zoom in to a record and see all of its details). For user convenience, we can also add predefined filters to the list view's search box. The search box options are configured through a search view component.

Our specification for the app includes a work team feature: that is, the ability to select a list of people that will be working on the task. So, we need a model to represent people. Odoo includes the Contact model (with the technical name of res.partner) to use for individual people, companies, and addresses.

The To-do Item model should include a work team field, which will allow us to select a list of people. We want to limit the people that can be selected to be part of work teams. For this, we will modify the Contact model to add a field for this: a Is Work Team? flag. Only people with this flag enabled can be added to a work team.

Odoo is a software product published by Odoo SA, a software company based in Belgium founded by Fabien Pinckaers. The Odoo software is company-driven, meaning that its roadmap and development are both tightly controlled by Odoo SA. However, it still follows open source principles, and community contributions to the code are welcome.

The Odoo software follows the open core business model, meaning that some parts of the software are open source and some parts are proprietary. As a result of this model, Odoo publishes two editions:

The Odoo EE works as a layer of additional modules on top of the Odoo CE core, offering premium features that are expected to provide enough value to motivate users to upgrade. The revenue from the Odoo EE funds the development for both the Odoo CE and EE. The Odoo founder and CEO Fabien Pinckaers has repeatedly pledged a commitment to keeping 80% of the code as open source in the Odoo CE and 20% in the proprietary Odoo EE.

The biggest strength of any open source project is the community around it. Odoo has an active community of contributors. For the Odoo product, the community contributes with feature feedback, translations, security issue reports, bug fixes, and occasionally some technical improvements to the core product. The Odoo CE is developed at

The Odoo core project does not offer a space to host these community module efforts, so they are developed in a dispersed way, with no common standards and quality controls. The Odoo Community Association (OCA) was created to address this issue. It provides the space to host community-contributed modules, along with common coding standards, guidelines, quality controls, and the tools for these workflows. The OCA code repositories can be found at , and the published modules can also be browsed at -community.org/shop.

At the time of writing, Odoo's latest stable version is version 15, marked on GitHub as branch 15.0. This is the version we will work with throughout this book. Major stable versions of Odoo are released on a yearly basis at the annual Odoo Experience conference every October.

The last three stable versions are officially supported. With the release of version 15, versions 14 and 13 are still supported, but versions up to 12 have no official support. This means that they don't receive bug and security fixes anymore.

Odoo databases are incompatible between its major versions. If you run an Odoo 15 server against a database created for a previous major version of Odoo, it won't work. Non-trivial migration work is needed before a database can be used with a later version of Odoo.

The same is true for addon modules. As a general rule, an addon module developed for a major Odoo version will not work on other versions. When downloading a community module from the web, make sure it targets the Odoo version you are using.

The Odoo Online SaaS edition may use intermediary versions, which are sometimes called the SaaS versions. These are also officially supported. The current list of supported versions can be checked at , in the Practical Information section of the Support page.

It's useful to understand the layers involved in the Odoo architecture and the role of each type of component we will use. So, we will now take a look at the Odoo application architecture and focus on how we can help application development by decomposing work into several component layers.

Odoo relies on its Object Relational Mapping (ORM) engine as the interface between the apps and the database. The ORM provides the application programming interface (API) used by the addon modules to interact with the data. We implement the Data tier using ORM models. For example, the Partner data entity, which is used for data records such as customers or suppliers, is represented by a model.

As a general rule, the low-level database should only be accessed by this layer because it ensures secure access control and data consistency. ORM models are based on a Python object class that supports several interaction methods, such as the CRUD basic operations. In particular, these CRUD operations are implemented by the create(), search(), write(), and unlink() model methods.

The Logic tier is responsible for all of the interactions with the Data tier and is handled by the Odoo server. The basic CRUD operations can be extended to implement specific business logic. For example, the create() and write() methods might implement default values or some other automation. Other code methods can be added to enforce validation rules or automatically compute field values.

The Presentation tier is responsible for presenting data and interacting with the user. It is implemented by the client part of the software, which is responsible for end user interaction. The client software uses remote procedure calls (RPCs) to the Odoo service, running the ORM engine and the business logic. The ORM API calls are sent to the Odoo server for processing to read, write, verify, or perform any other action. Then, the results are sent back to the client for further handling.

A website framework is also available to use as a public frontend for external users. It provides CMS features, allowing us to create both static and dynamic web pages. The website framework uses controller components for the code implementing the presentation-specific logic, keeping it separate from the model's intrinsic logic. The page rendering uses QWeb as the templating engine. These are XML documents that contain HTML markup plus specific XML QWeb tags for operations such as loops, conditions, or calls to include other templates.

The Odoo server API is open, and all server functions are available through it. The server API used by the official web client is the same as the one available to any other application. So, other client implementations are possible and could be built in almost any platform or programming language. Desktop and smartphone applications can be built to provide specific user interfaces, leveraging the Odoo Data and Logic tiers for business logic and data persistence.

You will be asked to select the first app to install in the new database. For the purpose of following this chapter, any choice will work for us, so feel free to choose any of the proposed apps. If you're unsure, the CRM app is a good choice.

The free trial will be valid for a period of 15 days. At the time of writing, the Odoo SaaS edition offers a free plan that allows you to keep this database running after this period (as long as you have more than one app installed).

Using an Odoo SaaS trial database will be the default choice for this chapter. For the rest of the book, we will use a local Odoo installation, and in Chapter 2, Preparing the Development Environment, we will guide you through this process.

Odoo packages can be downloaded from They are available for all stable Odoo versions, as well as for the master branch corresponding to the latest development version. We will explain each of these options in the following sections.

3a8082e126