Por accidente, integramos la mensajería de Odoo a Codize

A veces la informática no la entendemos ni los propios informáticos. Quienes estén al tanto de nuestro trabajo con la app Codize sabrán que cada característica nueva implica no solo tiempo de desarrollo y testeo, sino también mayor tiempo de mantenimiento de la plataforma cada año que Odoo saca una actualización. Porque es así, por muy estables que sean las versiones desde Odoo 11, un cambio mínimo al nombre de un campo hace que cada nueva versión sea un desafío. La plataforma de Codize no puede mantenerse en cada versión sin sufrir atrasos, más aún cuando el equipo de desarrollo es muy chico como el nuestro. Sabiendo todo esto, ¿por qué Codize soporta ahora la mensajería de Odoo? ¿era necesario?

Siendo sincero el pedido de mensajería de Odoo a sistemas móviles es algo bastante recurrente en nuestros usuarios, amigos y clientes. No obstante, para nada supera los pedidos de agregar más caracteristicas a la parte de órdenes de venta, facturación o el POS. Entonces, ¿por qué perdimos tiempo haciendo el desarrollo? La respuesta está en el sistema de Notificaciones de Odoo.

¿Notificaciones en Odoo?

Aunque no lo crean Odoo tiene un sistema de notificaciones similar al de cualquier red social tradicional, y no me estoy refiriendo a los carteles de error, sino a notificaciones de uso interno. Por ejemplo, cuando aignan un usuario a una tarea o hay un error en el envío de un mail, el usuario debería recibir una notificación. Y digo "debería" porque es un ideal, no es lo que ocurre siempre. También llegan notificaciones si escriben por una chat, ya sea un visitante u otro usuario, o el mismo Odoo Bot. Para un usuario de Odoo todas las notificaciones van al mismo lugar, pero para un desarrollador no es tan evidente.

El modelo que maneja las notificaciones se llama mail.notifications y es parte de un módulo masivo llamado mail. Realmente esta idea de arquitectura de Odoo de mezclar el manejo de mails, con el de las notificaciones, con el de los mensajes internos me parece una muy mala idea. Opiniones a parte, el mail.notifications solo trae notificaciones internas del sistema, y es muy complejo filtrarlas ya que no hay un campo de agrupación. Además a un usuario promedio le interesan solo unas pocas, la mayoría tienen otra finalidad. Hay que ir analizando el objeto que te devuelve, comprobar que no sea una notificación leída y recién ahí interpretar la notificación para elegir si mostrarla o no. Para colmo me encontré con que ese modelo nada tiene que ver con las notificaciones de mensajes, que de alguna manera son notificaciones, son mensajes y son mail al mismo tiempo. Para eso hay que hacer uso del mail.channel y del mail.messages. Odoo al mostrar una notificación lo que hace es agrupar todo bajo la lógica del sistema, y sin contar los problemas de usuarios suscriptos a canales o a determinadas notificaciones.

Codize y las Notificaciones

Hace unos días quicimos implementar las notificaciones de Odoo en Codize, algo así como una demo para que los usuarios que empiezan a utilizarla puedan recibir un mínimo feedback de la plataforma si es que hay errores. Iba a ser algo muy simple y beta, pero nos encontramos con que mail.notifications no terminaba de ser convincente, y las únicas que tenían cierto sentido de mostrar eran las de mail.channel (es decir, la mensajería). Así que la mensajería se implementó en Codize por accidente. Debemos mencionar al paso que una vez se tiene una plataforma estable (como Codize), este primer modelo beta de mensajería no fue tan tedioso de implementar como a priori se pueda suponer. La mayor dificultad se encuentra con el campo message_unread, el cual es imprescindible para saber que mensajes no fueron leidos. El problema es que es un campo computado (ya que usa al usuario interno como dato) y no se puede usar para filtrar los canales de comunicación. Esto supone un problema de rendimiento, así que ya estamos probando soluciones. Algunas capturas:

Siguientes pasos en la mensajería

La inclusión de archivos adjuntos es algo que Odoo tiene muy bien trabajado, y luego de leer casi todo el código de mail.channel y mail.message (una indigestión de código que no le recomiendo a nadie) llegué a la conclusión de que implementar algo así no es tan descabellado y podría ser muy útil. Desde ya que si tuviera que elegir algo para agregar es un linkeo con Firebase para hacer notificaciones Push. Ampliaremos.