Introducción
Si alguna vez ha guardado un formulario en Odoo y ha visto un campo volverse rojo, ya ha encontrado el mecanismo de campo requerido. Es una de las características más fundamentales en el modelo de datos de Odoo y una de las formas más simples de garantizar la calidad de los datos en sus flujos de trabajo empresariales.
Ya sea que esté configurando Odoo para un equipo de ventas, estableciendo un modelo personalizado o trabajando en un proyecto de desarrollo técnico de Odoo, entender cómo funciona el atributo required le ayudará a construir procesos más confiables.
Esta guía cubre todo: cómo se comporta el campo en el marco de Odoo, cómo configurarlo utilizando Odoo Studio o código Python, cuándo usarlo y qué errores debe evitar.
¿Qué es el campo requerido en Odoo?
En Odoo, el atributo required es una restricción a nivel de campo que impide que un registro se guarde a menos que el campo contenga un valor. Se aplica a prácticamente todos los tipos de campo de Odoo: campos de texto, campos numéricos, campos de selección, campos many2one, fechas y más.
Es parte del modelo de datos central de Odoo y es uno de los atributos más comúnmente utilizados al realizar personalizaciones en Odoo. Establecer un campo como requerido es la primera línea de defensa contra datos incompletos o inconsistentes en tu base de datos.
Cómo Aparece en la Interfaz
En la interfaz de usuario de Odoo, los campos requeridos se distinguen visualmente de los opcionales. Cuando un formulario está en modo de edición, los campos requeridos suelen mostrar un indicador visual sutil. Cuando un usuario intenta guardar el registro sin completar un campo requerido, Odoo resalta el campo en rojo y muestra un mensaje de advertencia.
Este comportamiento es consistente en toda la interfaz web. Los usuarios ven una retroalimentación inmediata y clara, lo que reduce la posibilidad de enviar registros incompletos.
Requerido Estático vs. Dinámico
Hay dos formas de hacer que un campo sea requerido en Odoo. La primera es un requerido estático: el campo siempre es obligatorio, sin importar qué. La segunda es un requerido dinámico: el campo se vuelve obligatorio solo cuando se cumplen ciertas condiciones, basadas en los valores de otros campos en el mismo registro.
Ambos enfoques se utilizan regularmente en el desarrollo de Odoo. La elección depende de tu lógica empresarial.
Cómo funciona el campo
Entender cómo funciona el atributo required a nivel técnico te ayuda a aplicarlo correctamente y a depurar problemas cuando surgen.
Aplicación de la Fuerza a Nivel de Aplicación
Un detalle importante que sorprende a muchos usuarios de Odoo: el atributo required se aplica a nivel de aplicación, no a nivel de base de datos. Esto significa que la restricción es verificada por el ORM de Odoo cuando se crea o se escribe un registro, antes de que los datos lleguen a la base de datos.
No se añade una restricción NOT NULL a la columna subyacente de PostgreSQL por defecto cuando estableces required=True en un campo. La validación ocurre en Python, dentro de la capa ORM de Odoo.
En la práctica, esto significa que los datos insertados directamente en la base de datos (eludiendo Odoo) no serán capturados por la restricción requerida. Siempre interactúe con los campos de la base de datos de Odoo a través del ORM o la API para beneficiarse de esta protección.
Qué sucede cuando se viola la restricción
Cuando un usuario intenta guardar un formulario con un campo requerido dejado vacío, suceden dos cosas:
- El campo se vuelve rojo en la interfaz y Odoo muestra un mensaje de validación
- La operación de guardado se bloquea hasta que se complete el campo
Si activa la validación programáticamente (por ejemplo, a través de la API XML-RPC o una acción del servidor), Odoo genera un ValidationError con un mensaje que indica qué campo requerido falta.
Requerido dinámico usando dominios
En el marco de Odoo, el atributo required puede hacerse condicional utilizando expresiones a nivel de vista. En Odoo 16 y versiones anteriores, esto se hace con el atributo attrs en el XML de la vista:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />En Odoo 17 y versiones posteriores, la sintaxis se simplifica con una expresión required directa en la etiqueta del campo en la vista:
<field name="x_delivery_date" required="order_type == 'delivery'" />Estas reglas condicionales residen en la capa de vista, no en la capa de modelo. Esta es una distinción importante: el required=True a nivel de modelo siempre impone la restricción, mientras que las expresiones a nivel de vista solo se aplican en contextos específicos de la interfaz.
Interacción con el ORM y la API
En el ORM de Odoo, cuando llamas a create() o write() en un modelo, el ORM verifica todos los campos con required=True antes de ejecutar la operación en la base de datos. Si falta un campo requerido o está establecido en False, Odoo genera un ValidationError.
Esto también se aplica al crear registros a través de la API XML-RPC. Cualquier campo marcado como requerido en la definición del modelo debe ser proporcionado en el diccionario de datos pasado al método create, o la llamada fallará con un error.
Casos de uso empresarial
Los campos requeridos aparecen en todo Odoo estándar, y son igualmente útiles en configuraciones personalizadas. Aquí hay cinco ejemplos concretos de flujos de trabajo empresariales reales donde hacer un campo requerido marca una diferencia genuina.
1. CRM: Segmento de Cliente Requerido en Oportunidades
Un equipo de ventas quiere asegurarse de que cada oportunidad esté asignada a un segmento de cliente antes de ser movida al embudo de ventas. Sin un campo requerido, los representantes de ventas a menudo omiten este paso, lo que hace imposible informar sobre las fuentes de oportunidades por segmento más tarde.
Al marcar un campo de selección personalizado "Segmento de Cliente" como requerido en el formulario de oportunidades de CRM, el equipo asegura que los datos siempre se capturen en el punto de entrada. Sin segmento, no se guarda.
2. Ventas: Dirección de Entrega Requerida en Pedidos
Para las empresas que envían bienes físicos, la dirección de entrega es crítica. En algunas configuraciones de Odoo, el campo de dirección de entrega no es requerido por defecto, lo que significa que los pedidos pueden ser confirmados sin uno.
Hacer que el campo de dirección de entrega sea requerido en el formulario de pedido de ventas evita que el pedido sea confirmado antes de que el equipo de logística tenga la información que necesita. Esto elimina una fuente común de errores en el proceso de cumplimiento.
3. Inventario: Lote o Número de Serie Requerido en Recepción
Para las empresas que operan en industrias reguladas (alimentos, farmacéuticos, electrónica), rastrear los números de lote en los bienes recibidos no es opcional. Odoo admite esto de forma nativa a través de la configuración de seguimiento en los productos, lo que efectivamente impone un número de lote o serie requerido durante los movimientos de stock.
Para los campos personalizados en los formularios de recibo, como una referencia de control de calidad, hacer que el campo sea obligatorio asegura que el equipo de almacén nunca olvide registrar la información durante el proceso de recepción.
4. Contabilidad: Centro de Coste Obligatorio en las Facturas de Proveedores
Los equipos de finanzas a menudo necesitan que cada gasto esté asignado a un centro de coste para el seguimiento del presupuesto. Sin una imposición, los contables o gerentes de compras pueden dejar el campo en blanco, creando lagunas en los informes financieros.
Un campo many2one obligatorio que apunta al modelo de centro de coste, añadido al formulario de la factura del proveedor, asegura que no se pueda publicar ninguna factura sin esta asignación. Este tipo de personalización de Odoo es rápida de implementar y tiene un impacto directo en la integridad de los datos.
5. RRHH: Tipo de Contrato Obligatorio Antes de la Incorporación
Los equipos de RRHH que gestionan la incorporación de empleados en Odoo a menudo quieren asegurarse de que el tipo de contrato esté registrado antes de que se finalice el registro del empleado. Un campo obligatorio en el formulario del empleado impide que el equipo de RRHH guarde inadvertidamente un registro de empleado incompleto durante un período de incorporación ocupado.
Creación o personalización del campo
Hay dos formas principales de marcar un campo como obligatorio en Odoo: utilizando Odoo Studio para un enfoque sin código, o escribiendo código Python para un control total. Ambos son válidos dependiendo de tu contexto.
Usando Odoo Studio
Odoo Studio es la herramienta integrada sin código que te permite configurar campos sin ningún desarrollo. Cuando abres Studio y seleccionas un campo en un formulario, verás un interruptor de "Obligatorio" en el panel de propiedades del campo a la derecha.
Activar este interruptor marca el campo como obligatorio en la vista y almacena la restricción a nivel de modelo. Este es el enfoque más rápido para casos simples y no requiere conocimientos técnicos. Funciona bien tanto para campos estándar de Odoo como para campos personalizados añadidos a través de los campos de Odoo Studio.
La limitación de Studio es que solo configura una restricción obligatoria estática. Para un comportamiento obligatorio dinámico basado en otros valores de campo, necesitas editar directamente el XML de la vista o utilizar el enfoque técnico.
Enfoque Técnico: Campos de Python
En un módulo personalizado de Odoo, declarar un campo requerido es tan simple como agregar required=True a la definición del campo. Este es el patrón estándar en el desarrollo de campos de python en odoo:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Public Sector'),
],
string='Customer Segment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Cost Center',
required=True,
)Con este enfoque, la restricción se aplica a nivel de modelo, lo que significa que se aplica independientemente de qué vista o interfaz se utilice para crear el registro. No se puede eludir accediendo al registro a través de una vista diferente.
Requerido Dinámico en XML de Vista
Cuando la restricción requerida solo debe aplicarse bajo ciertas condiciones, agréguela a nivel de vista en lugar de a nivel de modelo. En Odoo 16:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />En Odoo 17:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Esta es una restricción solo de vista. Es menos estricta que un requerido a nivel de modelo, ya que solo se aplica cuando el registro se edita a través de la vista específica que contiene esta definición.
Creando Campos Requeridos a través de la API
Si utiliza la API XML-RPC para crear campos (como se cubre en otros artículos de la colección de Datos y API de Odoo), puede establecer required al llamar a create en ir.model.fields. Esto es parte de la guía estándar para desarrolladores de odoo para personalización programática:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Esto crea el campo y aplica la restricción requerida en un solo paso, lo cual es útil en flujos de trabajo de implementación automatizada para escenarios de creación de campos en Odoo.
Mejores prácticas
Marcar un campo como requerido parece sencillo, pero usarlo bien requiere reflexión. Aquí están las prácticas que te ahorrarán tiempo y evitarán frustraciones para tus usuarios.
1. Solo Haz Requeridos los Campos Cuando Realmente Lo Sean
Exigir en exceso los campos es uno de los errores de configuración más comunes en Odoo. Si un usuario no puede completar un formulario porque un campo es requerido pero la información aún no está disponible, encontrará soluciones alternativas (como ingresar valores de marcador de posición) que corrompen tus datos.
Antes de marcar un campo como requerido, pregúntate: ¿esta información siempre está disponible en el momento de la entrada? Si la respuesta no es un claro sí, considera hacerlo requerido en una etapa posterior (por ejemplo, en la confirmación en lugar de en la creación) o utiliza un requerido dinámico en su lugar.
2. Usa Validación Basada en Etapas en Lugar de Siempre Requerido
Para flujos de trabajo con múltiples pasos, como una oportunidad de CRM o una orden de fabricación, a menudo es mejor hacer cumplir los campos requeridos en etapas específicas en lugar de desde el principio. Esto se hace típicamente a través de restricciones de Python o acciones automatizadas que verifican los valores de los campos cuando el registro pasa a una etapa determinada.
Este patrón es más flexible y amigable para el usuario que hacer que cada campo sea requerido desde el primer día.
3. Combina Campos Requeridos con Valores Predeterminados Donde Sea Sensato
Si un campo es requerido y tiene un valor predeterminado sensato para la mayoría de los casos, establece un default en la definición del campo. Esto reduce la fricción para los usuarios que no necesitan cambiar el valor predeterminado, mientras que aún asegura que el campo nunca esté vacío.
4. Prefiere Requeridos a Nivel de Modelo para Datos Críticos
Para datos que son realmente críticos (como información contable, identificadores regulatorios o identificadores obligatorios), aplica la restricción a nivel de modelo en Python en lugar de solo a nivel de vista. Las restricciones requeridas a nivel de vista pueden ser eludidas si un registro se crea a través de la API o una vista diferente que no incluye la restricción.
5. Comunicar los Campos Requeridos a los Usuarios Finales
Cuando añades nuevos campos requeridos a formularios existentes, los usuarios que están en medio de un flujo de trabajo pueden sorprenderse. Comunica los cambios a tu equipo antes de implementar, especialmente si los registros existentes pueden fallar en la validación en la próxima edición.
6. Probar con Datos Vacíos y Parciales
Antes de implementar una configuración con nuevos campos requeridos, siempre prueba el flujo de trabajo completo con valores vacíos y datos parciales. Esto incluye pruebas a través de la interfaz web, a través de la API y a través de cualquier acción automatizada o integración que cree registros en Odoo. Este es un paso básico en cualquier tutorial técnico responsable de Odoo.
Errores comunes
Incluso los implementadores experimentados de Odoo se enfrentan a problemas con los campos requeridos. Saber qué observar ahorrará tiempo de depuración y evitará retrocesos dolorosos.
Trampa 1: Hacer un Campo Requerido en un Modelo que Ya Tiene Registros
Si añades required=True a un campo en un modelo que ya contiene miles de registros, y esos registros no tienen un valor para ese campo, puedes encontrar problemas cuando esos registros se editen la próxima vez. Los usuarios no podrán guardar ningún cambio hasta que completen el nuevo campo requerido.
Antes de implementar una restricción requerida en un campo existente, siempre verifica si los registros existentes ya tienen valores. Si no los tienen, realiza una migración de datos para poblar el campo primero.
Trampa 2: Confundir los Campos Requeridos a Nivel de Vista y a Nivel de Modelo
Establecer un campo como requerido en una vista (ya sea a través de Studio o XML de vista) no impone la restricción a nivel de modelo. Un registro creado a través de la API, una vista diferente o una importación eludirá por completo las restricciones requeridas a nivel de vista.
Si necesitas una restricción estricta, establece required=True en la definición del campo en Python. Este es un punto frecuentemente malinterpretado en la comunidad de tutoriales de campos de Odoo, y causa problemas reales de calidad de datos en producción.
Trampa 3: Campos Requeridos en Acciones Automatizadas o Programadas
Cuando una acción automatizada o una acción programada crea registros de forma programática, debe proporcionar valores para todos los campos obligatorios. Si la acción se escribió antes de que se añadiera un campo obligatorio, comenzará a fallar silenciosamente o con un error críptico después de que se implemente la restricción requerida.
Siempre revisa todo el código de creación de registros automatizados después de añadir un campo obligatorio a un modelo existente.
Trampa 4: Importar datos que faltan campos obligatorios
Al importar registros a través de CSV o la herramienta de importación de Odoo, los campos obligatorios que faltan en el archivo de importación harán que la importación falle. Este es en realidad el comportamiento correcto, pero sorprende a los usuarios que están acostumbrados a importar datos parciales.
Siempre incluye todos los campos obligatorios en tus plantillas de importación. Es una buena práctica documentar qué campos son obligatorios en tus directrices de importación de datos.
Trampa 5: Usar requerido en lugar de una restricción de Python para validación compleja
El atributo required solo verifica que un campo no esté vacío. No valida el contenido ni la relación entre campos. Para una validación más compleja (por ejemplo, asegurarse de que una fecha esté en el futuro, o que dos campos sean consistentes), utiliza un decorador @api.constrains en Python en su lugar.
Tratar de codificar la lógica empresarial solo en campos obligatorios conduce a configuraciones inflexibles que son difíciles de mantener.
Conclusión
El atributo campo obligatorio es una de las herramientas más simples en Odoo, pero tiene un impacto real en la calidad de tus datos. Usado correctamente, asegura que la información crítica siempre se capture en el momento adecuado en tus procesos empresariales. Usado incorrectamente, frustra a los usuarios y crea soluciones alternativas que hacen que tus datos sean menos fiables, no más.
La clave es entender la diferencia entre las restricciones obligatorias a nivel de modelo y a nivel de vista, ser deliberado sobre qué campos realmente necesitan ser aplicados, y pensar de antemano sobre cómo se comportará la restricción en flujos de trabajo automatizados e integraciones de API.
Ya sea que estés siguiendo una guía de desarrollador de Odoo, realizando un proyecto completo de personalización de Odoo, o simplemente ajustando un formulario en Odoo Studio, el atributo requerido vale la pena entenderlo a fondo. Es uno de esos detalles que separa una implementación limpia de Odoo de una que causa dolores de cabeza seis meses después de la puesta en marcha.
¿Necesita ayuda con su implementación de Odoo?
En Dasolo, ayudamos a las empresas a implementar, personalizar y optimizar Odoo en todas las funciones empresariales y niveles de complejidad. Ya sea que necesites ayuda para diseñar un modelo de datos sólido, configurar reglas de validación o construir módulos personalizados, nuestro equipo aporta tanto experiencia técnica como funcional a cada proyecto.
Si tiene preguntas sobre los campos obligatorios o cualquier otro aspecto de su configuración de Odoo, estaremos encantados de ayudarle. Póngase en contacto con nosotros y hablemos sobre lo que está construyendo.