Introducción
En Odoo, la organización de la información sigue una regla clara: cada tipo de dato de negocio —clientes, facturas, pedidos, productos— tiene su propia estructura definida. Esas estructuras viven en la base de datos como modelos; pensar en ellos como moldes que dictan qué campos existen y cómo se relacionan entre sí te ayuda a entender cómo fluye y se conserva la información en el sistema.
Para técnicos y consultores funcionales, dominar los modelos de Odoo no es opcional: es la base de toda personalización. Los modelos determinan los campos disponibles, las relaciones entre objetos y dónde encaja la lógica de negocio; manejar correctamente esa capa evita sorpresas al desplegar módulos o configurar procesos.
Pero, ¿dónde guarda Odoo la información sobre esos moldes? Ahí entra ir.model: es el catálogo interno que registra metadatos de todos los modelos del sistema. Si desarrollas módulos, integras vía API o depuras comportamientos, acabarás consultando ir.model para entender qué modelos existen y cómo están definidos.
¿Qué es el modelo ir.model?
ir.model actúa como el registro maestro de modelos: cada entrada corresponde a un modelo del sistema. Cuando declaras un modelo en Python o lo creas desde Odoo Studio, Odoo añade o actualiza una fila en ir.model para reflejar esa definición.
Forma parte del núcleo de Odoo y es utilizado por el módulo base. Tanto los modelos corrientes como los transitorios o los abstractos quedan representados en este registro —salvo los abstractos que no generan tabla física—; en cualquier caso, el registro centraliza la metadata.
ir.model convive con ir.model.fields, que contiene la definición de cada campo. Juntos proporcionan la capacidad de introspección: permiten que el sistema (y los desarrolladores) consulten qué campos existen, su tipo y atributos sin mirar directamente el código fuente.
Los desarrolladores consultan ir.model para listar modelos disponibles, comprobar cadenas de herencia o crear herramientas dinámicas que funcionen sobre cualquier modelo. Además, la API de Odoo (XML-RPC/JSON-RPC) expone este registro, facilitando la integración y la inspección remota.
Campos clave del modelo
Estos son los campos más relevantes de ir.model. Conocerlos te ayudará a interpretar correctamente la información registrada y a trabajar de forma más eficaz con la arquitectura de datos de Odoo.
1. name
Tipo: Char. Es la etiqueta legible del modelo, la que verás en la interfaz técnica y en herramientas de desarrollador. Suele ser traducible y ayuda a identificar el propósito humano del modelo en listados y menús.
2. model
Tipo: Char. El nombre técnico del modelo, el que se utiliza en el código (por ejemplo, res.partner o sale.order). Es obligatorio y suele indexarse para búsquedas rápidas en la base de datos.
3. info
Tipo: Text. Campo libre para notas o documentación interna sobre el modelo. Sirve para describir detalles de implementación o recordatorios; en muchos casos puede quedar vacío.
4. state
Tipo: Selection. Indica si el modelo procede del núcleo (base) o si fue creado manualmente (por Studio o código personalizado). Los modelos base suelen tener protecciones adicionales frente a cambios.
5. transient
Tipo: Boolean. Señala que el modelo es transitorio: su información es temporal y Odoo la limpia automáticamente. Se usa en asistentes y datos efímeros que no deben persistir indefinidamente.
6. field_id
Tipo: One2many (ir.model.fields). Relación con los campos definidos en el modelo. Cada registro aquí describe un campo concreto: nombre, tipo y atributos relevantes.
7. access_ids
Tipo: One2many (ir.model.access). Define los permisos por grupo para ese modelo: quién puede crear, leer, escribir o borrar. Es la base del control de acceso a nivel de modelo.
8. rule_ids
Tipo: One2many (ir.rule). Contiene las reglas de registro (record rules) que delimitan qué registros puede ver o modificar cada usuario, implementando seguridad a nivel de filas.
9. inherited_model_ids
Tipo: Many2many (ir.model). Lista los modelos padres cuando se utiliza herencia. Si creas un modelo que hereda de otro, aquí se registra esa relación para mantener la cadena de herencia clara.
10. modules
Tipo: Char. Campo calculado que enumera los módulos que definen o extienden ese modelo. Útil para rastrear dependencias y saber qué módulos afectan su comportamiento.
11. sort
Tipo: Integer. Orden de presentación en los menús técnicos: los valores más bajos aparecen antes. Empleado para organizar visualmente el listado de modelos.
12. constrains
Tipo: Text. Contiene código de validaciones Python declaradas con @api.constrains. Guarda la lógica de restricciones a nivel de registro.
13. post_constrains
Tipo: Text. Código de validaciones posteriores: similar a constrains, pero pensado para comprobaciones que deben ejecutarse después de otras operaciones.
14. sql_constraints
Tipo: Text. Definiciones de restricciones a nivel de base de datos (por ejemplo, índices únicos). Protege la integridad incluso fuera de la capa ORM de Odoo.
15. view_ids
Tipo: One2many (ir.ui.view). Campo calculado que lista las vistas asociadas al modelo. Facilita la inspección de las interfaces que muestran o editan sus registros.
16. record_count
Tipo: Integer. Campo calculado con el número de registros que contiene el modelo. Sirve para informes rápidos y para hacerse una idea del volumen de datos.
17. display_name
Tipo: Char. Representación legible que combina nombre y modelo para mostrar en listas o relaciones; es el texto que suele verse en menús y selectores.
18. create_date
Tipo: Datetime. Marca temporal de creación del registro en ir.model. Odoo lo gestiona automáticamente y sirve para auditoría.
19. create_uid
Tipo: Many2one (res.users). Usuario que creó el registro. Útil para seguimiento y trazabilidad de cambios en la estructura de datos.
20. write_date
Tipo: Datetime. Fecha y hora de la última modificación del registro. También la gestiona Odoo automáticamente.
21. write_uid
Tipo: Many2one (res.users). Usuario que realizó la última modificación. Ayuda en auditorías y resolución de incidencias.
22. active
Tipo: Boolean. Indicador de baja lógica: si es False, el registro está archivado y se considera obsoleto. Permite mantener historial sin eliminar datos.
23. id
Tipo: Integer. Identificador único en base de datos del registro ir.model. Se usa al referenciar el modelo desde APIs o pruebas internas.
24. restrict_functionality
Tipo: Boolean. Marca si el modelo tiene funcionalidades limitadas en ciertas ediciones de Odoo (por ejemplo, diferencias entre Community y Enterprise).
25. is_mail_thread
Tipo: Boolean. Indica si el modelo integra el sistema de mensajería (chatter). Los modelos con esta bandera admiten seguidores, mensajes y hilos de conversación.
26. is_mail_activity
Tipo: Boolean. Señala soporte para actividades: si está activado, el modelo puede planificar tareas, acciones pendientes y seguimiento mediante el planner de actividades.
Cómo se emplea este modelo en los flujos de trabajo
1. Ajustes técnicos y configuración
Los administradores usan el menú técnico para explorar los modelos. Lo que aparece en ese listado proviene de los registros en ir.model: nombre, descripción y número de campos ayudan a identificar cada entrada rápidamente.
2. Gestión de permisos
La seguridad a nivel de modelo se configura asignando derechos a grupos. access_ids en ir.model determina qué grupos pueden crear, leer, escribir o borrar registros, y por tanto define la superficie de acceso de cada modelo.
3. Personalización con Odoo Studio
Cuando se crean modelos personalizados desde Odoo Studio, el sistema genera entradas en ir.model con el estado manual y rellena la relación field_id con los campos creados por el usuario, sin necesidad de escribir código.
4. Descubrimiento para integraciones y API
Las integraciones externas consultan ir.model a través de XML-RPC o JSON-RPC para descubrir qué modelos existen y cómo están estructurados, evitando suposiciones rígidas y permitiendo flujos de sincronización dinámicos.
5. Desarrollo de módulos y depuración
En desarrollo, ir.model ayuda a entender la herencia entre modelos y a revisar qué campos hay disponibles. Inspeccionar inherited_model_ids y field_id facilita tomar decisiones antes de extender o modificar estructuras.
Cómo lo amplían los desarrolladores
Los desarrolladores rara vez modifican ir.model directamente; lo habitual es dejar que el registro se actualice al cargar módulos. Intervenir el registro manualmente puede provocar inconsistencias o romper actualizaciones futuras.
Herencia de modelos
Al declarar en Python algo como _inherit = 'res.partner', Odoo actualiza el registro correspondiente en ir.model para reflejar la relación padre-hijo. Esa vinculación mantiene la coherencia del registro de modelos y permite que las extensiones funcionen correctamente.
Añadir campos
Al crear nuevos campos en un modelo, el sistema genera registros en ir.model.fields que apuntan al modelo mediante model_id. El propio registro de ir.model no necesita cambios para cada nuevo campo; la relación lo refleja todo.
Extensiones en Python
No es habitual sobrescribir métodos de ir.model: forma parte del núcleo. Si hace falta ajustar comportamientos, la práctica recomendada es ampliar los modelos que describen los propios registros, no alterar el registro maestro.
Odoo Studio
Studio automatiza la creación de registros en ir.model e ir.model.fields al construir modelos personalizados. La bandera transient diferencia los modelos temporales; por su parte, los modelos abstractos no generan entradas en ir.model porque no crean tablas en la base de datos.
Buenas prácticas
- Consejo práctico: usa ir.model para descubrimiento
- Cuando desarrolles integraciones, consulta ir.model para listar modelos disponibles en vez de codificar nombres rígidos. Aprovecha el campo model (indexado) para búsquedas eficientes por nombre técnico.
- Antes de extender un modelo, revisa inherited_model_ids para comprender la cadena de herencia y evitar conflictos con módulos existentes.
- Para integraciones remotas, utiliza la API XML-RPC/JSON-RPC para leer ir.model. Evita modificar estos registros salvo que estés desarrollando una herramienta de tipo Studio o tengas razones muy concretas.
- Usa ir.model.fields para inspeccionar a nivel de campo: la relación field_id te da el detalle necesario para generar formularios dinámicos o mapeos de datos.
Errores frecuentes
- Evita modificar ir.model directamente
- La gestión del registro la realiza Odoo; editar estas entradas a mano puede causar fallos o que tus cambios se pierdan en una actualización. Trata ir.model como información de sistema, no como un lugar para ajustes puntuales.
- No confundir ir.model con la clase Python
- ir.model es el registro en la base de datos; la clase Python (el modelo ORM) es la implementación ejecutable. Ambos están relacionados pero no son lo mismo; entender esa distinción evita errores conceptuales al desarrollar.
- No todos los modelos generan registro en ir.model
Conclusión
Las clases abstractas no crean tablas ni entradas en ir.model. Tampoco debes usar la bandera transient para datos permanentes: los modelos transitorios se limpian automáticamente, por lo que no son adecuados para almacenar información a largo plazo.
En resumen: ir.model es el catálogo central de modelos en Odoo. Contiene la metadata esencial y, junto con ir.model.fields, permite inspeccionar la estructura de datos del sistema. Conocer su funcionamiento simplifica el trabajo de configuración, integración y desarrollo.
¿Necesitas ayuda con tu implementación de Odoo?
Tanto si te mueves por los ajustes técnicos como si integras Odoo con sistemas externos, entender ir.model te ahorrará tiempo y reducirá errores en tus implementaciones.
Dasolo ayuda a empresas a implementar, personalizar y optimizar Odoo. Nos especializamos en integraciones por API y desarrollo sobre la plataforma, con experiencia práctica en la arquitectura de datos y modelos como ir.model. Si necesitas apoyo con tu implementación de Odoo, desarrollo de módulos o integraciones, podemos ayudarte. Solicita una demo