XMLRPC en Odoo ¿por qué no me funciona?

Pocas cosas tienen una documentación más escasa que el XMLRPC de Odoo. Y es mucho decir, ya que -sin faltar- la documentación en Odoo es de las peores de los frameworks. Si buscamos XMLRPC en Odoo nos encontramos con esto: https://www.odoo.com/documentation/11.0/webservices/odoo.html

No parece una información incompleta, a priori, pero al momento de encarar una API de comunicación la cosa es algo más compleja. El problema radica en que hace falta "traducir" los ejemplos de comunicación de Odoo para el sistema que desee comunicarse en cuestión. Y entonces se nos va a sumar otro ingrediente más al juego: el lenguaje que se comunica. La pregunta de "¿por qué no me funciona?" es compleja, ya que puede deberse a una librería en concreto. Lo ideal es tratar de ubicar tres factores que son los que emplean la comunicación: URL, método y parámetros.

La URL es un string apuntando a la URL del servidor tal como accedemos online a Odoo (si tiene puerto, deberá llevarlo). Al mismo se le agrega "/xmlrpc" para acceder a la comunicación por dicho protocolo y luego otro directorio donde se especifica que vamos a buscar. En líneas generales se usan dos extensiones "/xmlrpc/common" para loguearse y "/xmlrpc/2/object" para acceder a la información de un modelo de Odoo. Por ejemplo, si el servidor es "http://www.moldeointeractive.com.ar" para acceder al login deberemos usar "http://www.moldeointeractive.com.ar/xmlrpc/common". 

El método es una función RPC para realizar cierta acción. El método "login" se emplean para loguearse, y el método "execute_kw" se usa para comunicarse con objetos de Odoo.

Los parámetros hacen un poco la magia final. Suele tratarse de un objeto expresado entre corchetes "[ ]" donde va distinta información en orden y separado por comas. Lo primero y básico es "base de datos, usuario, password". Sin embargo, el usuario no es el mismo que el del login, sino que será el UID de dicho usuario (que se obtiene de "/xmlrpc/common"). A partir de ahí podremos agregar parámetros dependiendo lo deseado. El cuarto parámetro es el modelo al cual queremos acceder a la información, por ejemplo "res.partner" y se expresa como un string. El quinto parámetro es otro string, la función a ejecutar sobre el modelo, y acá hay varias. Si queremos buscar todos registros de un modelo tenemos la función "search" que es rápida ya que solo devuelve los IDs de los registros. Si queremos toda la información podemos usar "search_read". Si queremos leer todos los registros sin ningún filtro, tenemos la función "read". Y también dispondremos de una función "write" para modificar el valor de un campo de un registro, y la función "create" para crear un registro dentro de un modelo. Las posibilidades son bastantes. El sexto y último parámetro es toda la cadena de filtros que queramos utilizar y variables opcionales. Por ejemplo, lo podemos utilizar para buscar todos res.partner que sean clientes. Un ejemplo de cadena de parámetros podría ser así:

["miDB", 4, "miPassword", "res.partner", "search_read", [[['customer', '=', true]]] ]

Es un poco la base que hay que entender tanto de sintaxis como de concepto. Pero cuidado, que hay trampa. Dependiendo el lenguaje y el framework, las funciones RPC se llaman como una suscripción (como con Ajax) o como una función en sí. En esos casos vamos a tener que hacer, por ejemplo "execute_kw()" y enviar los datos que necesita.