La capa modelo

Ahora que Odoo conoce nuestro nuevo módulo, comencemos agregándole un modelo simple.

Los modelos describen objetos de negocio, como una oportunidad, ordenes de clientes o socios (cliente, proveedor, etc.). Un modelo tiene una lista de atributos y también puede definir su negocio específico.

Los modelos se implementan utilizando una clase Python derivada de una clase de plantilla Odoo. Se traducen directamente a objetos de base de datos, y Odoo se encarga de esto automáticamente al instalar o actualizar el módulo. El mecanismo responsable de esto es el Modelo Relacional de Objetos (ORM).

Nuestro módulo será una aplicación muy simple para mantener las tareas pendientes. Estas tareas tendrán un solo campo de texto para la descripción y una casilla de verificación para marcarlas como completas. Más adelante deberíamos añadir un botón para limpiar la lista de tareas de las tareas completas.

Creando el modelo de datos

Las directrices de desarrollo de Odoo establecen que los archivos Python para los modelos deben colocarse dentro de un subdirectorio models. Para simplificar, no lo seguiremos aquí, así que vamos a crar un archivo todo_model.py en el directorio principal del módulo todo_app.

Añade el siguiente contenido:

# -*- coding: utf-8 -*- 

from odoo import models, fields 

class TodoTask(models.Model): 

    _name = 'todo.task' 

    _description = 'To-do Task'

    name = fields.Char('Description', required=True) 

    is_done = fields.Boolean('Done?') 

    active = fields.Boolean('Active?', default=True)

La primera línea es un marcador especial que indica al intérprete de Python que este archivo tiene UTF-8 para que pueda esperar y manejar caracteres no ASCII. No usaremos ninguno, pero es una buena práctica tenerlo de todos modos.

La segunda línea es una instrucción de importación de código Python, haciendo disponibles los objetosmodels y fields del núcleo Odoo.

La tercera línea declara nuestro nuevo modelo. Es una clase derivada de models.Model.

La siguiente línea establece el atributo _name que define el identificador que se utilizará en Odoo para referirse a este modelo. Toma en cuenta que el nombre real de la clase Python, TodoTask en este caso, carece de significado para otros módulos Odoo. El valor _name es lo que se utilizará como identificador.

Observa que esta y las siguientes líneas tienen sangría. Si no estás familiarizado con Python, debes saber que esto es importante: la sangría define un bloque de código anidado, por lo que estas cuatro líneas deben tener estar todas igual sangría.

Luego, tenemos el atributo modelo _description. No es obligatorio, pero proporciona un nombre fácil de usar para los registros del modelo, que puede utilizarse para mejores mensajes de usuario.

Las tres últimas líneas definen los campos del modelo. Vale la pena señalar que name y active son nombres de campos especiales. De forma predeterminada, Odoo usará el campo de name como el título del registro al referenciarlo de otros modelos. El campo active se utiliza para inactivar los registros y, por defecto, sólo los registros activos serán mostrados. Lo utilizaremos para borrar las tareas completadas sin eliminarlas de la base de datos.

En este momento, este archivo aún no es utilizado por el módulo. Debemos decirle a Python que lo cargue con el módulo en el archivo __init__.py. Vamos a editarlo para agregar la siguiente línea:

from . Importar todo_modelo

¡Eso es! Para que nuestros cambios de código de Python entren en vigor, la instancia de servidor debe reiniciarse (a menos que esté utilizando el modo --dev).

No veremos ninguna opción de menú para acceder a este nuevo modelo ya que no los hemos añadido aún. Sin embargo, podemos inspeccionar el modelo recién creado usando el menú Technical. En el menú superior Settings, ve a Technical | Database Structure | Models, busca el modelo todo.task en la lista y haz clic en él para ver su definición:

Si todo va bien, se confirma que el modelo y los campos fueron creados. Si no puedes verlos aquí, intenta reiniciar el servidor con una actualización de módulo, como se describió anteriormente.

También podemos ver algunos campos adicionales que no declaramos. Estos son campos reservados que Odoo agrega automáticamente a cada modelo nuevo. Estos son los siguientes:

• id es un identificador numérico único para cada registro del modelo.
• create_date y create_uid especifican cuándo se creó el registro y quién lo creó respectivamente.
• write_date y write_uid confirman cuándo el registro fue modificado por última vez y quien lo modificó respectivamente.
• __last_update es un ayudante que en realidad no se almacena en la base de datos. Se utiliza para verificaciones de concurrencia.

Añadiendo pruebas automatizadas

Las mejores prácticas de programación incluyen tener pruebas automatizadas para tu código. Esto es aún más importante para lenguajes dinámicos como Python. Como no hay ningún paso de compilación, no puede estar seguro de que no haya errores sintácticos hasta que el intérprete realmente ejecute el código. Un buen editor puede ayudarnos a detectar estos problemas con antelación, pero no puede ayudarnos a asegurar que el código se ejecute como lo desean las pruebas automatizadas.

Odoo soporta dos formas de describir las pruebas: ya sea utilizando archivos de datos YAML o utilizando código Python, basado en la biblioteca Unittest2. Las pruebas YAML son un legado de versiones anteriores, y no se recomiendan. Preferiremos usar pruebas de Python y añadiremos un caso básico de prueba a nuestro módulo.

Los archivos de código de prueba deben tener un nombre que empiece por test_ y se debe importar desde tests / __ init__.py. Pero el directorio de test (o submódulo Python) no se debe importar desde la parte superior del módulo __init__.py, ya que se descubrirá y cargará automáticamente sólo cuando se ejecuten pruebas.

Las pruebas deben colocarse en un subdirectorio test/. Añade un archivo tests / __ init__.py con lo siguiente:

from . import test_todo

Ahora, añade el código de prueba real disponíble en el archivo tests/test_todo.py:

# -*- coding: utf-8 -*- 

from odoo.tests.common import TransactionCase 

class TestTodo(TransactionCase): 

    def test_create(self): 

        "Create a simple Todo" 

        Todo = self.env['todo.task'] 

        task = Todo.create({'name': 'Test Task'}) 

        self.assertEqual(task.is_done, False)

Esto agrega un caso simple de prueba para crear una nueva tarea y verifica que el campo Is Done?Tiene el valor predeterminado correcto.

Ahora queremos hacer nuestras pruebas. Esto se hace agregando la opción --test-enable durante la instalación del módulo:

$ ./odoo-bin -d todo -i todo_app --test-enable

El servidor Odoo buscará un subdirectorio tests/ en los módulos actualizados y los ejecutará. Si alguna de las pruebas falla, el registro del servidor te mostrará eso.

La capa de lógica de negocio

Ahora vamos a añadir algo de lógica a nuestros botones. Esto se hace con código Python, utilizando los métodos de la clase de modelos Python.

Añadiendo lógica de negocio

Debemos editar el archivo Python todo_model.py para agregar a la clase los métodos llamados por los botones. Primero, necesitamos importar la nueva API, así que agréguala a la declaración de importación en la parte superior del archivo Python:

from odoo import models, fields, api

La acción del botón Toggle Done será muy simple: solo cambia la bandera Is Done?. Para la lógica de los registros, utiliza el decorador @api.multi. Aquí, self representará un conjunto de registros, y entonces deberíamos hacer un bucle a través de cada registro.

Dentro de la clase TodoTask, añade esto:

@api.multi 

def do_toggle_done(self): 

    for task in self: 

        task.is_done = not task.is_done 

    return True

El código pasa por todos los registros de tarea y, para cada uno, modifica el campo is_done, invirtiendo su valor. El método no necesita devolver nada, pero debemos tenerlo al menos para devolver un valor True. La razón es que los clientes pueden utilizar XML-RPC para llamar a estos métodos y este protocolo no admite funciones de servidor devolviendo sólo un valor None.

Para el botón Clear All Done, queremos ir un poco más lejos. Debe buscar todos los registros activos que están hechos, y hacerlos inactivos. Normalmente, se espera que los botones de formulario actúen sólo en el registro seleccionado, pero en este caso, queremos que actúe también en registros distintos del actual:

@api.model 

def do_clear_done(self): 

    dones = self.search([('is_done', '=', True)]) 

    dones.write({'active': False}) 

    return True

En los métodos decorados con @ api.model, la variable self representa el modelo sin registro en particular. Construiremos un conjunto de registros dones que contenga todas las tareas marcadas como terminadas. A continuación, establecemos el indicador active para False en ellos.

El método de búsqueda es un método API que devuelve los registros que cumplen algunas condiciones. Estas condiciones están escritas en un dominio, que es una lista de tripletes. Exploraremos los dominios con más detalle en el Capítulo 6, Vistas – Diseñando la interfaz de usuario.

El método write establece los valores de una vez en todos los elementos del conjunto de registros. Los valores a escribir se describen utilizando un diccionario. Usar write here es más eficiente que iterar a través del conjunto de registros para asignar el valor a cada uno de ellos uno por uno.

Añadiendo de pruebas

Ahora debemos agregar pruebas para la lógica de negocio. Idealmente, queremos que cada línea de código sea cubierta por al menos un caso de prueba. En tests / test_todo.py, agregua unas cuantas líneas más de código al método test_create ():

# def test_create(self): 

        # ... 

 # Test Toggle Done 

        task.do_toggle_done() 

        self.assertTrue(task.is_done) 

        # Test Clear Done 

        Todo.do_clear_done() 

        self.assertFalse(task.active)

Si ahora ejecutamos las pruebas y los métodos del modelo están correctamente escritos, no deberíamos ver ningún mensaje de error en el registro del servidor:

$ ./odoo-bin -d todo -i todo_app --test-enable