Cuando un campo Studio mal configurado tumba el POS y el SII por 12 horas

Esta semana ayudamos a una empresa con una caída completa de su Punto de Venta y de la emisión de Documentos Tributarios Electrónicos (DTE). El sistema estuvo inoperativo durante 12 horas. La causa: un campo creado desde Studio sin entender lo que el motor ORM de Odoo iba a hacer con él. El nombre y datos del cliente están omitidos, pero el patrón es replicable y suficientemente común como para que valga la pena documentarlo.

El síntoma

A las 09:14 AM, los cajeros reportan que el POS no abre. Mensaje en pantalla: "AccessError: You are not allowed to read this record". Minutos después, la cola de envío de boletas al SII también se detiene. El sistema queda en un estado donde nadie puede facturar ni vender.

El diagnóstico

El primer reflejo del equipo del cliente fue restaurar el último backup. No funcionó. El segundo intento fue reiniciar el contenedor Docker. Tampoco. El error volvía siempre al cargar el módulo de POS.

Cuando entramos a revisar logs, encontramos un patrón claro: cada vez que el ORM cargaba el modelo pos.order, fallaba al evaluar un campo computado llamado x_studio_pos_order_count. Ese campo había sido creado el día anterior por un usuario administrador, desde la interfaz de Studio, con la intención inocente de "contar cuántas órdenes tiene un cliente".

La fórmula del campo había quedado así (simplificada):

env['pos.order'].search_count([('partner_id', '=', record.id)])

A primera vista parece razonable. El problema: este campo se ejecuta cada vez que el ORM lee CUALQUIER registro de res.partner, y abre una transacción nueva contra pos.order. Cuando el POS se inicializa para un cajero sin permisos sobre todas las tiendas, esa transacción falla con AccessError, y el error se propaga hacia arriba rompiendo la inicialización del módulo entero.

El fix temporal

Lo primero fue desactivar el campo desde la base de datos directamente, sin pasar por Studio (que estaba inaccesible porque el módulo POS estaba caído). Una sentencia SQL contra ir_model_fields con state='manual' y store=false bastó para que el ORM dejara de evaluarlo. POS y DTE volvieron en menos de 5 minutos.

Lo que aprendimos

1. Studio no es un juguete. Cualquier campo que use env[...] dentro de su fórmula está ejecutando código real en cada lectura. Un error ahí puede tumbar módulos enteros.
2. Producción no es laboratorio. Un campo creado por curiosidad debe pasar primero por staging, especialmente si toca modelos críticos como res.partner o pos.order.
3. Los permisos importan. Un campo computado que asume permisos globales va a fallar para usuarios con scope reducido, y eso a veces no aparece hasta que un cajero específico intenta abrir el POS.
4. El backup no siempre te salva. Si el cambio es de schema (no de datos), restaurar la DB de ayer no soluciona nada — el campo malo ya está en el modelo.

¿Cómo prevenirlo?

Tres cosas que recomendamos siempre a clientes que usan Studio:

• Limitar el grupo "Configuración Studio" a una o dos personas técnicas.
• Tener un ambiente de staging idéntico a producción y probar todo cambio ahí primero (incluso los "inocentes").
• Hacer auditorías trimestrales de los campos custom — saber qué se agregó, por qué, y si se sigue usando.

Si tu Odoo crece sin gobernanza, este tipo de incidente se vuelve cuestión de tiempo. Un audit de seguridad anual cuesta menos que 12 horas de POS caído.