Odoo follows a multi-tier architecture, and we can identify three main tiers: Data, Logic, and Presentation:

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 RDBMS, and this is a design choice. So, other databases such as MySQL are not supported. Binary files, such as attachments of documents or images, are usually stored in a filesystem.

The Logic tier is responsible for all the interactions with the data layer, and is handled by the Odoo server. As a general rule, the low-level database should only be accessed by this layer, since it is the only way to ensure security access control and data consistency. At the core of the Odoo server, we have the Object-Relational Mapping (ORM) engine for this interface. The ORM provides the application programming interface (API) used by the addon modules to interact with the data.

For example, the Partner data entity, such as a Customer or a Supplier, is represented in the ORM by a model. This model is a Python object class supporting several interaction methods, such as create() to create new Partner records, or read() to query existing records and their data. These generic methods can implement specific business logic in particular Models. For example,  the create() method might implement default values or enforce validation rules; the read() method might support some automatically computed fields, or enforce access controls depending on the user performing that action.

The Presentation tier is responsible for presenting data and interacting with the user. It is implemented by a client responsible for all the user experience. The client interacts with the ORM API to read, write, verify, or perform any other action, calling ORM API methods through remote procedure calls (RPCs). These are sent to the Odoo server for processing, and then the results are sent back to the client for further handling.

For the Presentation tier, Odoo provides a full-featured web client out of the box. The web client supports all the features needed by a business application: login sessions, navigation menus,  data lists, forms, and so on. The global look and feel are not as customizable as a frontend developer might expect, but it makes it easy to create a functional and consistent user experience.

A complementary presentation layer is the included website framework. It gives full flexibility to create web pages as the exact user interface intended, like in other CMS frameworks, at the expense of some additional effort and web expertise. The website framework supports web controllers to implement code for presenting specific logic, keeping it separate from the model intrinsic logic. Frontend developers will probably feel very much at home in this space.

Due to the openness of the Odoo server API, other client implementations are possible, and could be built in almost any platform or programming language. Desktop and smartphone apps can be built to provide specific user interfaces, leveraging the Odoo Data and Logic tiers for business logic and data persistence.

A particular example of a third-party Odoo client is ERPpeek. It is a command- line client, allowing you to connect and interact with remote Odoo servers. It can be useful for developers or system administrators with Odoo technical knowledge, to inspect data on the server, script advanced operations, or perform maintenance operations. We will present an overview of ERPpeek in Chapter 8, External API – Integrating with Other Systems.

Many Odoo customizations can be made directly from the user interface.

This has the advantage of being a rather quick way to make changes to applications. It can be used from small modifications, such as adding a field, to larger customizations, such as creating an app with several models, views, and menu items.

These customizations done directly from the user interface have some limitations, when compared to customizations done with programming tools, covered throughout the rest of this book. For example, you can't add or extend ORM methods (although Automated Actions can be used as a close alternative to that). They also can't be easily integrated into a structured development workflow, such as running automated tests and deploying into several environments (for example, quality assurance, pre-production, and production).

Odoo 10.0 introduced Odoo Studio, an app designer to create customizations from the user interface. We won't discuss Odoo Studio here, but it ends up being a user-friendly frontend for the developer tools we introduce throughout this chapter, so the limitations on customizations possible are about the same. Odoo Studio does include an important additional feature, that is, the ability to export the customizations done in a convenient module package. It can be very helpful to allow power users to create customizations in a SaaS instance or simpler self-hosted technical environments.

The remainder of this book explains how to develop for Odoo in a structured way, creating addon modules with your code editor.

But in this chapter, we will be using the Developer mode features to perform customizations directly from the web client user interface, since it is important for an Odoo developer to have a good understanding of these tools and what can be achieved with them.

But more importantly, the goal for this exercise is to gain a good understanding of the several layers involved in an Odoo application, and how their components are organized.

Enough talk; let's get busy trying out these tools.

To explain the developer tools, we will use a simple project: we will create a very simple Library app. Our Library aims to keep a record of our Books and their Authors. It should keep a list of the Authors and the Books authored by each Author.

Our Library app needs two Models: Authors and Books. These two Models have a many-to-many relationship between them: each Author can have many Books, and each Book can have many Authors.

Odoo already provides the built-in Partner Model, with the res.partner technical name, to represent people, organizations, and addresses. For example, customers, suppliers, contact people, and application users are all Partners.

We will make our life simpler if we reuse it for the Authors of our Library app. We will be adding an Is Book Author? flag to this Model, and a menu item showing only the Author Partners.

The book we will create has a completely new Model, the corresponding form, and list views, and a menu item to access them.

We will be needing an Odoo test database to work with.

In Chapter 2, Installing and Organizing the Development Environment, we will explain how to install Odoo from source and set up our development environment. But we want to skip that for now, and start working directly from the user interface of some existing Odoo server.

If by chance you have a self-hosted Odoo installation working, that's perfect; we can use it to go through the rest of this chapter. At the login screen, access the Manage Databases menu option and create a new database to play with.

If you don't have an Odoo installation available, you can instead create a test database at Odoo.com to follow this chapter. The user interface there will be from the Odoo Enterprise Edition, so it will be a little different from the screenshots you will find here, but that should not be a problem. To create a new database, you will probably be asked to select a starting app. No specific app is required to follow this chapter, but if you're unsure on what to pick, CRM would be fine.

Now, access the Odoo database with your browser and log in. For Odoo online, the address should be something like https://<mydbname>.odoo.com. For a self-hosted instance, it should be something like http://<server-address>:8069. The 8069 port is the Odoo default. If your installation uses a different port, you should change it accordingly.

We will be using the Contacts Directory app, so the first thing to do is to install it. Open the Apps top menu, look up this app, and install it, if you have not already done so:

Now that we have an Odoo instance to work with, the next step is to enable the developer tools, that give us the access to the Odoo internals.

In Settings | Dashboard, at the bottom right, you can find the Activate the developer mode link. Clicking on it enables the Developer mode features for this browser window.

We also have available an Activate the developer mode (with assets) option. What it does is to prevent web client asset minification. It is useful to debug the web client itself, at the expense of making the navigation a little slower.

For faster load times, the web client minifies the Javascript and CSS assets into compact files. Unfortunately, that makes web client debugging nearly impossible. The Activate the developer mode (with assets) option prevents this minification and loads the web assets in individual, non-minified files.

Once the Developer mode is enabled, we will see two additional menus available:

• The Debug menu, the bug icon at the right-hand side of the top menu bar, just before the username and avatar
• The Technical menu item, in the Settings app:

We will be explaining and making use of these Developer mode features in the next sections of this chapter.