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.

Throughout this chapter, we will use an example project to illustrate the concepts being presented. The project will be to build a simple to-do list Odoo app.

We want the app to allow us to add new to-do items to a list and then mark them as completed. For example, we want to be able to add a Buy eggs to-do item to the list and then check an Is done? checkbox once the task is completed. Additionally, the to-do items should be private to each user – in other words, the current user should be able to access only their own to-do items. To make the project more interesting, we will introduce an additional complication – our to-do items should be able to include a list of the people involved in the task: the work team.

It is useful to think about our application by considering the tiers involved:

• Data tier: This tier is implemented through models.
• Business Logic tier: This tier is implemented through Python automation code.
• Presentation tier: This tier is implemented through views.

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.

We will follow these steps to build the to-do list app:

1. Create the new model for the to-do items.
2. Create the menu items to make them available to users.
3. Configure the access control security.
4. Create the list and form views for the to-do items.

The new To-do Item model should have these fields:

• A Description character field
• An Is Done? flag, which is a Boolean field

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.

For the work team feature, we need to add a field to the Contact model and the form view.

Before we go into the actual implementation, we will first discuss a few basic concepts relating to the Odoo framework, and then learn how to prepare an environment to work with.

There are a few concepts that might not be obvious to people first learning about Odoo. Let's try to understand these before moving on.

About Odoo and the Odoo community

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 Community Edition (CE) is publicly available, open source, and licensed under LGPL.

The Enterprise Edition (EE) is available only to official partners and customers and has a proprietary license requiring non-disclosure of the code.

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 https://github.com/odoo/odoo.

Beyond the Odoo core product, the community publishes additional Odoo modules that add features. Many individuals and companies in the Odoo community make their Git repositories publicly available under open source licenses. They also publish them in Odoo Apps – which is the official Odoo app store: apps.odoo.com. The app store allows for both free and paid modules.

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 https://github.com/oca, and the published modules can also be browsed at https://odoo-community.org/shop.

Odoo product versions

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.

Major releases – such as 15.0 – are expected to receive frequent updates, but these should be mostly bug fixes and not new features. They are guaranteed to be API-stable, meaning that model data structures and view element identifiers will remain stable. This is important because it means there will be no risk of custom modules breaking due to incompatible changes in the upstream core modules.

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 https://www.odoo.com/documentation/user, in the Practical Information section of the Support page.

The version in the master branch version will result in the next major stable version, but until then, it's not API-stable and you should not use it to build custom modules. Doing so is like moving on quicksand – you can't be sure when changes will be introduced and they could break your custom module. You have been warned.

The Odoo architecture

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 applications can be decomposed into three tiers: the Data, Logic, and Presentation tiers:

Figure 1.1 – The Odoo application layers

The Data tier is the lowest-level layer and is responsible for data storage and persistence. Odoo relies on a PostgreSQL server for this. PostgreSQL is the only supported database server in Odoo, and this is a design choice. Binary files – such as the attachments of documents or images – are stored in the filesystem in a directory referred to as filestore.

Note

This means that a full backup of an Odoo instance needs both a database dump and a copy of filestore.

We will rarely use SQL to interact directly with the database engine; however, this is possible and might be needed in particular cases.

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.

Odoo provides a web client out of the box. The web client supports all of the features needed by a business application, such as login sessions, navigation menus, data lists, and forms.

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.