Understanding basic Odoo concepts
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.