Skip to main content

About the Odoo base Models

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 relevant examples are these:
  • ir.actions.act_window for Windows Actions
  • ir.ui.menu for Menu Items
  • ir.ui.view for Views
  • ir.model for Models
  • ir.model.fields for Model Fields
  • ir.model.data for XML IDs
The resources contain basic data about the world, which can be useful for applications in general. These are the more important resource models:
  • res.partner for business partners, such as customers, suppliers, and so on, and addresses
  • res.company for company data
  • res.currency for currencies
  • res.country for countries
  • res.users for application users
  • res.groups for application security groups
This should provide you with useful context to better understand where the models come from whenever you come across them in the future.
Labels:

Comments

Post a Comment

Popular posts from this blog

The message and activity features

The message and activity features Odoo has available global  messaging  and activity planning features, provided by the  Discuss  application, with technical name mail. The mail module provides the  mail.thread  abstract class that makes it simple to add the messaging features to any model, and the  mail.activity.mixin  that adds planned activity features. This was done in  Chapter 4 ,  Extending Modules , to explain how to inherit features from mixin abstract classes. To add these features, we need to add the mail dependency to the add-on module,  library_checkout , and then have the library checkout model class inherit from the abstract classes providing the following features. Edit the  'depends'  key in the  library_checkout/__manifest__.py   file, to add the mail module, shown as follows: Copy 'depends': ['library_member' , 'mail' ], And edit the  library_checkout/m...
Post a Comment
Read more

Setting up an nginx reverse proxy

Setting up an nginx reverse proxy While Odoo itself can serve web pages, it's strongly recommended that there is a  reverse  proxy positioned in front of it. A reverse proxy acts as an intermediary that manages the traffic between clients sending requests and the Odoo servers responding to them. Using a reverse proxy has several benefits. On the security side, it can do the following: Handle (and enforce) HTTPS protocols to encrypt traffic Hide the internal network characteristics Act as an application firewall, limiting the URLs accepted for processing Also, on the performance side, it can provide the following significant improvements: Cached static content, hence reducing the load on the Odoo servers Compressed content to speed up loading time Act as a load balancer, distributing load between several servers Apache is a popular choice when considering a reverse proxy, although  nginx  is a recent alternative with good technical argumen...
4 comments
Read more

The QWeb template language

The QWeb template language The  QWeb  parser looks for special directives in the templates and replaces them with dynamically generated HTML. These directives are XML element attributes and can be used in any valid tag or element, such as  <div> ,  <span> , or  <field> . Sometimes, we may want to use a QWeb directive but we don't want to place it in any of the XML elements in our template. For those cases, we have a  <t>  special element that can have QWeb directives, such as  t-if  or  t-foreach , but is silent and won't have any output on the final XML/HTML produced. The QWeb directives will frequently make use of evaluated expressions to produce different results, depending on the current record values. There are two different QWeb implementations: client-side JavaScript and server-side Python. The reports and website pages use the server-side Python implementation of QWeb. Kanban views us...
1 comment
Read more