LC ODOO SERVICE

About the Odoo base Models In the previous chapters, we had the chance to  create  new Models, such as the Book model, but we also made use of the already existing Models, such as the Partner Model, provided by Odoo out of the box. We will have here a basic introduction to these built-in models. At the core of Odoo, we have the  base  add-on module. It provides the essential features needed for Odoo apps. Then, we have a set of built-in add-on modules, providing the official apps and features made available with the standard product. The base module provides two kinds of Models: Information Repository,  ir.*  models Resources,  res.*  models The  Information Repository  is used to store data needed by  Odoo  to know how to work as an application, such as Menus, Views, Models, Actions, and so on. The data we find in the  Technical  menu is usually stored in information repository models. Some ...

Model constraints Often, applications need to ensure data integrity, and enforce some validations to  ensure  that data is complete and correct. The PostgreSQL database manager supports many useful validations, such as avoiding duplicates, or checking that values meet certain simple conditions. Model can declare and use PostgreSQL constraints for this. Some checks require more sophisticated logic, and are better implemented as Python code. For these cases, we can use specific model methods implementing Python constraint logic. SQL model constraints SQL constraints are added to the  database  table definition and are enforced directly by PostgreSQL. They are  defined using the  _sql_constraints  class attribute. It is a list of tuples, and each tuple has the format  (name, code, error) : name  is the constraint identifier name code  is the PostgreSQL syntax for the constraint error  is the error messa...

Computed fields Fields can have their  values  automatically calculated by a function, instead of simply reading a  database  stored value. A computed field is declared just like a regular field, but has the additional  compute  argument to define the function used for its computation. In most cases, computed fields involve writing  some  business logic. So, to take full advantage of this feature, we need to learn the topics explained in  Chapter 8 ,  Business Logic - Supporting Business Processes . We can still explain computed fields here, but will keep the business logic as simple as possible. Let's work on an example. Books have a publisher. We would like to have the the publisher's country in book form. For this, we will use a computed field, based on the  publisher_id , which will take its value from the publisher's  country_id  field. We should edit the book model in the  library_app/models...

Relationships between models Non-trivial business application have a structured data model, and need to relate the data from the different entities involved. To do this, we need to use relational fields. Looking again at our Library app, in the book model we can see the following relationships: Each book can have one publisher. This is a   many-to-one relationship , implemented in the   database   engine as a foreign key. The inverse is a   one-to-many relationship , meaning that each publisher can have many books. Each book can have many authors. That's a   many-to-many   relationship. The inverse relationship is also a many-to-many, since each author can have many books. We will explore each of these relationships in the next sections. A particular case is hierarchical relationships, where records in a Model are related to other records in the same Model. We will introduce a book category model to explain that case. Finally,...