Los campos readonly en Odoo parecen una solución simple, pero acaban condicionando flujos, auditorías y permisos más de lo que aparentan.
Tanto si te preguntas por qué ciertos campos aparecen desactivados como si eres quien debe diseñar la lógica de la aplicación, esta guía te explica las decisiones que importan alrededor del comportamiento readonly.
Comprender cuándo y cómo bloquear la edición de un campo evita incoherencias de datos, mantiene trazabilidad y reduce consultas del equipo operativo.
Aquí encontrarás tanto la visión funcional para administradores y consultores como las pautas técnicas para desarrolladores que construyen sobre Odoo.
¿Qué es el atributo readonly en Odoo
En Odoo, un campo readonly muestra información pero no permite que el usuario la modifique desde la interfaz: se ve el valor, pero el control de entrada está deshabilitado.
En los formularios, los campos readonly suelen renderizarse como texto estático en lugar de un input activo; dependiendo del tema pueden mostrarse en un tono apagado o simplemente sin el contorno editable.
En la plataforma existen dos niveles donde se aplica el comportamiento readonly dentro del modelo de datos:
- A nivel de campo (Python/ORM): la restricción es global y afecta a todas las vistas y contextos
- A nivel de vista (XML): la restricción se aplica solo en esa vista o bajo una condición determinada
La diferencia es clave: si bloqueas un campo en el ORM nadie podrá escribir en él desde la UI ni por API; si lo bloqueas en la vista, el campo puede seguir siendo editable en otros contextos o por procesos de servidor.
Readonly no es un tipo de dato distinto, sino una propiedad que puedes añadir a cualquier tipo de campo de Odoo — Char, Integer, Float, Many2one, Date, etc. — para controlar su comportamiento en tiempo de ejecución.
Cómo funciona el atributo readonly
Para saber cómo se comportan estos campos conviene revisar tanto la capa de datos (ORM en Python) como la de presentación (XML en vistas).
Readonly en el ORM (nivel Python)
En el modelo Python puedes declarar un campo con readonly permanente, opción habitual en campos calculados cuya fuente proviene de otros datos. En la definición se usa readonly=True y el sistema impide su edición desde la UI.
Este tipo de restricción forma parte de la API de fields de Odoo y se aplica de forma global, independientemente de la vista que cargue la interfaz.
Readonly según el estado del documento
Un patrón recurrente es condicionar la edición de un campo al estado de un documento: cuando una orden deja de estar en borrador, ciertos campos se bloquean para preservar el histórico, igual que hacen los módulos estándar de ventas o compras.
En versiones anteriores de Odoo se configuraba con attrs en la vista XML; en versiones más recientes la sintaxis para condiciones inline es más limpia, pero el propósito sigue siendo el mismo.
El resultado esperado es siempre el mismo: editable en borrador y bloqueado cuando el flujo avanza. Este mecanismo es básico para coordinar validaciones y el estado de negocio en Odoo.
Campos computados y readonly
Los campos computados vienen por defecto como readonly porque su valor se deriva automáticamente de otros campos y no tiene sentido que el usuario los sobrescriba directamente.
Si además quieres que ese valor se almacene en la base de datos para búsquedas y ordenación, activas store=True: así mejoras rendimiento y puedes indexarlos como campos normales.
Hacer que un campo computado sea editable
Si necesitas permitir entradas manuales en un campo computado, debes definir una función inversa (inverse). Esa función indica cómo aplicar un valor escrito por el usuario al modelo subyacente; sin inverse, el campo sigue siendo readonly.
Casos de uso en la empresa
Los campos readonly aparecen en todos los módulos. A continuación tienes cinco ejemplos prácticos con impacto real en procesos empresariales.
1. CRM: asegurar los datos de oportunidades ganadas y perdidas
Mientras una oportunidad está en gestión, importe y fecha de cierre son editables; al cerrar como Ganada o Perdida se bloquean para preservar el registro histórico del cierre.
Así se evita que alguien altere cifras retrospectivamente y distorsione informes comerciales y métricas de pipeline.
2. Ventas: proteger las líneas de pedido confirmadas
Al confirmar un pedido, las líneas dejan de ser editables: producto, cantidad y precio se bloquean para que el cliente reciba una confirmación firme.
Si es imprescindible modificar algo, la práctica correcta suele ser volver a borrador con el proceso correspondiente, generando estado y trazabilidad de la corrección.
3. Inventario: cantidades validadas en movimientos
Cuando un albarán se valida, las cantidades reales realizadas se fijan. Esto evita discrepancias entre el stock físico y lo registrado para valoración y trazabilidad.
Permitir cambios tras la validación puede provocar desajustes acumulados entre ubicaciones y afectar inventarios globales.
4. Contabilidad: asientos publicados
Una vez publicado un asiento, sus líneas quedan bloqueadas por motivos de cumplimiento y coherencia contable en muchos países.
Editar después de la publicación compromete la fiabilidad de los estados financieros y puede crear problemas legales y fiscales.
5. Fabricación: datos de órdenes de trabajo finalizadas
Al marcar una orden de trabajo como terminada se fijan tiempo real y cantidades producidas; esos registros alimentan análisis de costes y desempeño y deben conservarse sin alteraciones casuales.
Crear o personalizar un campo readonly
Hay dos caminos principales para configurar readonly: herramientas no-code como Odoo Studio o la vía técnica mediante Python y XML para tener control fino.
Usando Odoo Studio
Odoo Studio permite activar o desactivar readonly sin tocar código. Es ideal para administradores que necesitan reglas sencillas y rápidas de aplicar.
- Abre Odoo Studio desde el menú principal (icono del lápiz)
- Accede al formulario donde quieres modificar el campo
- Selecciona el campo objetivo
- En el panel de propiedades a la derecha activa la opción «Readonly»
- Guarda y cierra Studio
Studio también admite condiciones readonly con expresiones de dominio, por ejemplo bloquear un campo solo cuando un estado toma cierto valor, todo sin escribir una línea de código.
La opción de Studio es recomendable para consultores y administradores que desean cambios rápidos y seguros ante actualizaciones: las modificaciones quedan en la base de datos y no se sobrescriben con upgrades habituales.
Usando Python para personalización técnica
En desarrollo, se marca readonly en la definición del field dentro del modelo Python. Esta es la forma estándar para añadir restricciones permanentes en módulos personalizados.
Puedes usar readonly=True para bloqueo fijo, o el parámetro states para definir en qué estados el campo es editable o no, ofreciendo control según la lógica del documento.
Esta técnica es especialmente útil cuando amplías modelos estándar con campos nuevos: la lógica queda cercana al modelo y no repartida en múltiples vistas.
Usando atributos en la vista XML
Para comportamientos readonly a nivel de presentación se añade el atributo readonly en el elemento field dentro del XML de la vista — la práctica habitual en personalizaciones visuales.
La ventaja del nivel vista es la flexibilidad: el mismo campo puede comportarse distinto en formularios, listas o kanban sin tocar su definición en Python; perfecto para imponer restricciones puntuales sin tocar el modelo.
En Odoo 17 la expresión inline para condiciones readonly es más clara respecto al antiguo uso de attrs; ambas siguen siendo válidas según la versión del sistema.
Buenas prácticas
Aplicar readonly de forma eficaz consiste en elegir el nivel correcto y justificar la decisión en términos de flujo de negocio y mantenimiento.
1. Prefiere readonly en la vista cuando el contexto varíe
Si la necesidad es condicional (solo en ciertos estados o vistas), aplícalo en la vista para mantener el modelo flexible y permitir a procesos back-end o integraciones escribir cuando sea necesario.
2. Alinea las condiciones readonly con el ciclo de vida del documento
Bloquea campos cuando alcanzan un estado en el que editarlos causaría inconsistencias; así la UX resulta predecible y reduce errores operativos.
3. Prueba con distintos perfiles de usuario
El comportamiento readonly puede interactuar con permisos. Verifica cómo se ve el campo como usuario estándar y como administrador: una restricción aparente puede no aplicarse a todos los roles si no está bien planteada.
4. Combina readonly con required donde tenga sentido
En formularios multi-etapa, un campo puede ser obligatorio en borrador pero readonly más adelante. Defínelo así para forzar completar datos críticos antes de avanzar el flujo.
5. Documenta la lógica detrás del readonly
En desarrollos complejos deja comentarios que expliquen por qué un campo está bloqueado: futuros mantenedores entenderán la razón de negocio, no solo la implementación técnica.
6. Usa Studio para cambios rápidos y seguros ante upgrades
Si la lógica es sencilla, Studio es la vía más ágil y resistente a actualizaciones; reserva Python para condiciones complejas o integraciones con campos computados.
Errores habituales
Incluso quienes dominan Odoo tropiezan con trampas comunes al usar readonly. Conocerlas evita dolores de cabeza más adelante.
Confundir readonly en la vista con una barrera de seguridad
Un readonly en la vista no impide escrituras vía XML-RPC, llamadas ORM o acciones de servidor. Si necesitas bloquear totalmente un campo, hazlo en el ORM o mediante reglas de acceso, no solo en la interfaz.
Hacer un campo permanentemente readonly cuando debería ser condicional
Cerrar un campo a nivel de modelo por comodidad puede impedir flujos legítimos como reabrir documentos para correcciones. Evalúa el ciclo completo antes de optar por un bloqueo definitivo.
Olvidar los métodos onchange
Un onchange puede intentar escribir sobre un campo readonly, provocando comportamientos erráticos donde el valor parece cambiar y luego revierte o lanza errores. Asegúrate de que la lógica onchange respete las restricciones de edición.
No aplicar readonly de forma consistente en todas las vistas
Si sólo bloqueas un campo en un formulario puede seguir editándose desde una vista lista o kanban. Revisa todas las vistas donde aparece el campo para evitar inconsistencias.
Efectos colaterales al heredar modelos estándar
Marcar readonly=True sobre un campo heredado cambia su comportamiento en todas las vistas, incluidas las estándar. Comprueba que esto no rompa procesos ni otras personalizaciones antes de imponerlo a nivel de modelo.
Resumen
Los campos readonly son una herramienta esencial para guiar a los usuarios, mantener la integridad de la información y aplicar reglas de negocio sin depender exclusivamente de formación.
La clave está en decidir si el bloqueo debe vivir en la vista o en el modelo y en asegurarse de que las condiciones reflejen cómo trabaja realmente tu equipo.
Tanto si empleas Odoo Studio para un enfoque sin código como si prefieres definir las reglas en Python y XML, el objetivo es el mismo: mostrar datos y protegerlos frente a cambios no deseados.
No son el tema más llamativo en las personalizaciones, pero su efecto en la fiabilidad y el control de procesos es enorme.
En Dasolo acompañamos a empresas en la implantación, personalización y optimización de Odoo en todos los módulos y sectores. Si necesitas ayuda con campos, flujos o modelado de datos, te podemos apoyar. Contacta con nosotros y cuéntanos tu proyecto.