Buenas Prácticas en Odoo

Una de las cosas más potentes de Odoo como ERP es su posibilidad de personalizar una implementación a las necesidades del cliente, tanto desde la propia interfaz de Odoo como desde la programación. Sin embargo, a la hora de crear un módulo, muchas veces no nos damos cuenta que una solución a un Bug puede no estar bien integrada y perderse en un futuro, u ocasionar problemas de compatibilidad.

Hagan módulos

Quizás sea la mejor práctica de todas. Si van a implementar algo nuevo en un Odoo, mejor hacerlo en un nuevo módulo. Lo que sea, modificar un css, agregar JavaScript, modificar un Campo con Python, modificar una View, crear un Template, lo que sea. No se tiene ni se debe modificar un módulo de Odoo, sino extenderlos con otro módulo, nuestro módulo, un módulo personalizado. Para esto, la opción de hacerlo con Scaffold es una buena alternativa:

./odoo-bin scaffold mimodulo /odoo/custom/addons/

También es fundamental colocar dicho módulo en una ruta personalizada y no utilizar la ruta de addons de Odoo.

Conocer la Arquitectura

¿No saben en que View poner su interfaz? Suele pasar. Conocer la arquitectura de Odoo es fundamental al momento de crear un módulo, ya que nos servirá para elegir la View donde queremos incluir nuestras interfaces. Sin embargo, es necesario tener un criterio de desarrollo a la hora de crear archivos que conformen el módulo.

¿Cuando es conveniente crear un nuevo XML? Lo ideal es uno individual para cada conjunto de Views (un archivo XML para modificar vistas del website, uno distinto para modificar el sale.order, etc), uno individual para cada reporte, y uno para cada nuevo template que creemos. Estos archivos es conveniente ubicarlos en una carpeta llamada views. Del mismo modo, los archivos de Python deben estar en una carpeta models y los controllers en una carpeta llamada controllers. No es una convención, pero es como actualmente Odoo organiza sus módulos.

Para el caso de nuestras imágenes, CSS, JS y demás, nos guiaremos por la convención actual de recursos estáticos. Necesitamos crear en el root del módulo una carpeta llamada static que contenga una carpeta src, y esta última contendrá carpetas como css (que incluye todo el css de nuestro módulo), less (para incluir archivos de css preprocesado), js (para archivos JavaScript) y img (carpeta para imágenes).

La UX es importante

Dos palabras: Interfaz y Wizard. No importa que el cliente o la empresa nos asegure que va a entender toda la implementación, siempre es mejor proveer un sistema claro. La interfaz de Odoo es bastante modular, hay lugares donde suelen incluirse botones y otros donde incluir menú. Lo importante es adaptar nuestro sistema a Odoo, y no poner botones y desplegables en cualquier parte. Del mismo modo, si la implementación requiere de varios pasos (por ejemplo, implementar un sistema de presupuesto y factura relacionados) es conveniente crear un wizard que muestre como utilizar el sistema en sí. Esto es especialmente útil porque una empresa puede adquirir nuevos empleados en un futuro, y el uso de un Wizard puede ahorrar una capacitación o, al menos, hacerla un poco más llevadera.

Server, Bases de Pruebas y Backups

"No siempre testeo mi código, pero cuando lo hago, lo hago en Producción"

Un error común de principiantes es ir implementando los pedidos de cliente en base de Producción, en lugar de probarlo primero en un server con bases de prueba. Odoo provee esta función de forma gratuita, y es conveniente aprovecharla.

Situación: Una empresa pide a un desarrollador implementar unos features en la generación de remitos de su Odoo. El desarrollador acepta el trabajo y lo realiza en unas horas, reinicia el server y actualiza el módulo. Al otro día, la empresa le dice que los números de los productos no están coincidiendo con el de los remitos y piden al desarrollador dar marcha atrás con la implementación. El desarrollador no hizo backup de la base de datos ni del módulo anterior, le quedará tratar de volver el módulo a su estado anterior (si es que lo recuerda) y corregir esos números mediante algún tipo de script en Python. Mientras tanto, al empresa no podrá usar la función de remitos.

A ninguno nos gustaría vernos en una situación similar (salvo que a veces, por circunstancias que no están en nuestro control, solemos vernos en estas dificultades). Lo importante es disminuir este tipo de situaciones, y la mejor forma es trabajar con otro server y bases de prueba. En este server pasaremos bases de producción para tenerlo actualizado, pero podremos estar tranquilos y hacer cualquier tipo de modificación en el, ya que no afecta la productividad de la empresa que necesita tener un Odoo funcionando bien todo el día. En este server implementaremos los features, los probaremos, pero también podremos pedirles a los integrantes de la empresa en cuestión que lo testeen en prueba. De este modo, solo pasaremos el módulo a producción cuando la empresa nos de el visto bueno. Esto no solo reducirá problemas, sino que además le dará la responsabilidad de testear a la empresa y no caerá todo en quien desarrolla.

Usar Git

¿Saben que hace años que ya existe Git? Para el que viva en una burbuja, Git es un sistema de control de versiones donde podremos tener nuestro código en un repositorio. Esto nos permite dar marcha atrás implementaciones que no resultaron, hacer ramificaciones y mezclar código entre distintos desarrolladores. Esto último es especialmente importante para Odoo, ya que, en nuestro caso, solemos trabajar en un equipo (pequeño, pero un equipo al fin y al cabo). Además, existe un sistema online llamado Github que almacena el código (como nuestros módulos) brindando no solo un backup, sino también la posibilidad de utilizarlo en otras implementaciones de un modo rápido y seguro. En caso de necesitar un repositorio privado (muchos clientes pueden solicitar que su código no sea libre), Github provee de repositorios privados por una tarifa mensual; o puede utilizarse Bitbucket que permite repositorios privados gratuitamente.