For the to-do tasks to have a kanban board, we need stages. Stages are the board columns, and each task will fit into one of these columns.
Let's add the following code to the todo_ui/todo_model.py file:
# -*- coding: utf-8 -*-
from openerp import models, fields, api
class Tag(models.Model):
_name = 'todo.task.tag'
name = fields.Char('Name', 40, translate=True)
class Stage(models.Model):
_name = 'todo.task.stage'
_order = 'sequence,name'
_rec_name = 'name' # the default
_table = 'todo_task_stage' # the default
name = fields.Char('Name', 40, translate=True)
sequence = fields.Integer('Sequence')Here, we created the two new Models we will be referencing in the to-do tasks.
Focusing on the task stages, we have a Python class, Stage, based on the class models.Model, defining a new Odoo model, todo.task.stage. We also defined two fields, name and sequence. We can see some model attributes, (prefixed with an underscore) that are new to us. Let's have a closer look at them.
Model classes can have additional attributes used to control some of their behaviors:
_name: This is the internal identifier for the Odoo model we are creating._order: This sets the order to use when the model's records are browsed. It is a text string to be used as the SQLorder byclause, so it can be anything you could use there._rec_name: This indicates the field to use as the record description when referenced from related fields, such as a many to one relation. By default, it uses thenamefield, which is a commonly found field in models. But this attribute allows us to use any other field for that purpose._table: This is the name of the database table supporting the model. Usually, it is left to be calculated automatically, and is the model name with the dots replaced by underscores. But it can be set to indicate a specific table name.
For completeness, we can also have the _inherit and _inherits attributes, as explained in Chapter 3, Inheritance - Extending Existing Applications.
Odoo models are represented by Python classes. In the preceding code, we have a Python class Stage, based on the models.Model class, used to define a new Odoo model todo.task.stage.
Odoo models are kept in a central registry, also referred to as pool in the previous versions. It is a dictionary keeping references of all the model classes available in the instance, and can be referenced by model name. Specifically, the code in a model method can use self.envl['x'] or self.env.get('x') to get a reference to a class representing model x.
You can see that model names are important since they are the key used to access the registry. The convention for model names is to use a list of lowercase words joined with dots, like todo.task.stage. Other examples from the core modules are project.project, project.task or project.task.type. We should use the singular form: todo.task instead of todo.tasks. For historical reasons it's possible to find some core models not following this, such as res.users, but that is not the rule.
Model names must be globally unique. Because of this, the first word should correspond to the main application the module relates to. In our example, it is todo. Other examples from the core modules are project, crm, or sale.
Python classes, on the other hand, are local to the Python file where they are declared. The identifier used for them is only significant for the code in that file.
Because of this, class identifiers are not required to be prefixed by the main application they relate to. For example, there is no problem to call just Stage to our class for the todo.task.stage model. There is no risk of collision with possible classes with the same name on other modules.
Two different conventions for class identifiers can be used: snake_case or CamelCase. Historically, Odoo code used snake case, and it is still very frequent to find classes using that convention. But the recent trend is to use camel case, since it is the Python standard defined by the PEP8 coding conventions. You may have noticed that we are using the latter form.
In the preceding code, and in the vast majority of Odoo models, classes are based on the models.Model class. This type of models have database persistence: database tables are created for them and their records are stored until explicitly deleted.
But Odoo also provides two other model types to be used: Transient and Abstract models.
Transient models are based on the models.TransientModel class and are used for wizard-style user interaction. Their data is still stored in the database, but it is expected to be temporary. A vacuum job periodically clears old data from these tables.
Abstract models are based on the models.AbstractModel class and have no data storage attached to them. They act as reusable feature sets to be mixed in with other models. This is done using the Odoo inheritance capabilities.
The information about models and fields created with Python classes is available through the user interface. In the Settings top menu, select the Technical | Database Structure | Models menu item. Here, you will find the list of all models available in the database. Clicking on a model in the list will open a form with its details.
This is a good tool to inspect the structure of a Model, since you have in one place the result of all additions that may come from several different modules. In this case, as you can see at the In Modules field, on the top right, the todo.task definitions are coming from the todo_app and todo_user modules.
In the lower area, we have some information tabs available: a quick reference for the model Fields, the Access Rights granted, and also list the Views available for this model.
We can find the model's External Identifier, by activating the Developer Menu and accessing its View Metadata option. These are automatically generated but fairly predictable: for the todo.task model, the External Identifier is model_todo_task.