NationwideLegal.

El contexto

El cliente es NationwideLegal. Su operación comercial vive en un CRM: oportunidades, las firmas a las que pertenecen, los contactos de cada firma y las direcciones que hay detrás. Polargate construyó ese CRM sobre Odoo 18 Enterprise y desde entonces lleva su dirección técnica.

Todo lo hecho a medida vive en un único módulo propio. No depende de nada más allá de módulos Community, así que no hay ningún complemento de terceros en el camino crítico. El módulo aporta cinco modelos nuevos, cada uno con su fichero de permisos completo y sin huecos, y extiende los modelos nativos de oportunidades, contactos, actividades y etapas.

La cadena de entrega es deliberadamente aburrida: repositorio privado, proyecto gestionado de Odoo y la producción del cliente apuntando al mismo entorno. La plataforma corre la suite de tests en cada build de desarrollo y de preproducción. El paso a producción nunca es automático, lo dispara una persona a mano. Del merge a la versión viva en producción pasan de diez a quince minutos.

Permisos montados sobre cómo vende el equipo

Rehicimos el modelo de acceso alrededor de cómo trabajan los comerciales, con cuatro controles separados por usuario en lugar de un único rol monolítico. A un usuario se le puede dar uno y no los otros, que es lo que necesita un equipo comercial y lo que un rol único no sabe expresar.

El calendario

Cada comercial ve sus propias actividades. El administrador las ve y las gestiona todas. Llegar ahí no fue una regla de registro. En Odoo, la lectura de actividades no se gobierna con reglas de registro, porque ese modelo trae su propia búsqueda y su propia comprobación de acceso nativas, así que hubo que resolverlo por otra vía. Se verificó con la cuenta de un comercial.

Dar de alta usuarios sin ser administrador

En Odoo no existe de serie un rol intermedio que pueda crear usuarios sin ser administrador. Lo verificamos en un entorno local: el único grupo nativo con ese permiso se auto eleva a administrador en una sola escritura. Así que construimos un grupo propio, con su lista de control de acceso y una barrera en el propio modelo. No puede dejar a nadie con grupos de administrador, no puede modificar a un usuario que ya lo es y no puede escribir la contraseña de otro. Verificado en navegador con una cuenta que solo tiene ese permiso.

Entrada de datos parecida a la herramienta de la que venían

Empresa, dirección y contacto se meten en una sola página, como funcionaba la herramienta que el equipo usaba antes. La detección de duplicados corre sobre un nombre normalizado e indexado que ignora la puntuación y los sufijos legales: avisa y ofrece asociar el registro al que ya existe en vez de crear un segundo. La lista de sufijos hubo que podarla, porque algunas de sus palabras juntaban en uno solo a dos despachos realmente distintos.

Correo transaccional

El correo sale por la capa de autenticación: autenticación SMTP habilitada y la cuenta de envío configurada, de modo que cada mensaje transaccional sale desde el CRM.

Actualizaciones que se pueden deshacer

No dimos por buena la clasificación de riesgo de una migración: la ensayamos en contenedor, de forma reproducible. El hallazgo: al quitar un campo del modelo, la plataforma no borra la tabla ni las columnas, las deja huérfanas con el dato dentro. Las filas sembradas sobrevivieron al upgrade y la vuelta atrás devolvió el código y el acceso al dato, 132 filas y 56 relaciones sobre 200 registros. La migración es reversible, y lo es porque se probó, no porque lo diga la documentación.

Verificación contra producción, después de cada despliegue

Hay una receta escrita y se ejecuta después de cada despliegue. Leer la versión viva del módulo. Comprobar la vista contra la definición combinada, no contra la de herencia. Confirmar que los campos nuevos existen. Cronometrar su lectura sobre registros reales: 400 oportunidades respondieron en 313 ms, que es la comprobación de que no se ha colado ni un bucle ni una consulta pesada. Descargar el paquete de assets y validarlo, porque un paquete roto no se ve hasta que un usuario abre la página. La disciplina es dura y simple: en producción se mira y no se toca.

Las auditorías funcionan igual. La primera fase consiste en ejecutar el escenario contra un entorno real, suplantando al usuario afectado y anotando el estado antes y después de cada escritura. Validar un permiso con una cuenta de administrador no prueba nada, porque el bypass la exime. Un test que solo comprueba el texto de un atributo tampoco prueba nada. Una de esas auditorías movió 41 agentes y 2,3 millones de tokens, con dos escépticos independientes rebatiendo cada hallazgo antes de darlo por bueno.

Dirección tecnológica continuada

Quince entregables completados en cinco semanas y consolidados en un documento de entrega. El módulo pasó de no tener tests propios a 99 en verde, con los casos negativos verificados también, porque un test de permisos que pasa cuando debería fallar es peor que no tener test.

El encargo funciona con una regla sencilla: el alcance y la prioridad se acuerdan antes de entrar en la lista, y Polargate emite el documento de referencia semanal.