Parche para el issue 24800 aceptado por Openbravo

Openbravo ha aceptado el parche que envié en el issue 24800. No es gran cosa pero nos evita tener que hacer un fork del core. En esta ocasión tenía un problema para hacer una personalización de la contabilidad de la factura de compra, si quería replicar fielmente el proceso original que contabiliza la factura de compra era necesario que dos métodos de la clase DoInvoice fueran public. Una vez replicado el comportamiento original ya podíamos hacer la personalización.

 

Cheli

Calidad del Soporte de Openbravo

Llevo unos meses trabajando con Sidesoft en un proyecto bastante grande de implantación de Openbravo ERP en la empresa Flopec (La flota petrolera ecuatoriana). En todo proyecto y más cuando son de esta envergadura surgen problemas, por suerte el core de Openbravo sigue siendo libre (licencia MPL) y siempre que he tenido un problema he podido arreglarlo por mi cuenta y presentarle una solución a mi cliente. El caso de Sidesoft es el ideal ya que la localización ecuatoriana la hemos desarrollado nosotros y está licenciada bajo la GPL3, gracias a ello no necesitamos ningún módulo privativo de Openbravo ERP, esto le posibilita a Sidesoft como implantador el poder ofrecer a sus clientes la posibilidad de no tener  que adquirir la versión profesional, lo cual abarata muchísimo los costes. Esto sería prácticamente imposible en una implantación española ya que la localización es propiedad de Openbravo y la versión completa sólo está disponible en la versión profesional, además de ser privativa.

El problema en realidad no son los costes, el problema es que la versión profesional no nos aporta mucho por regla general (ya tenemos lo que necesitamos en Ecuador) y lo que ofrece es generalmente módulos privativos que por una parte nos limitan (no se pueden redistribuir ni reutilizar siempre que no se pague una versión profesional en cada implantación), no siguen nuestra filosofía de ofrecer software libre lo  que nos quita la ventaja competitiva de cara a nuestros clientes y por otra parte el soporte no suele ayudar mucho, de entrada por mucho que pagues es lento y casi siempre tenemos que desarrollar nosotros mismos una solución de emergencia.

En el caso de Flopec el cliente decidió contratar la versión profesional así que teníamos la posibilidad de acceder al soporte. Voy a exponer uno de los problemas que tuvimos y lo que ha pasado de momento con el soporte.

 

El primer problema es que en la nueva ventana de gestión de cobros y pagos avanzados que surgió como módulo en Openbravo ERP 2.50 y que finalmente sustituyó a la anterior forma de gestionar la cartera en la versión 3.0 tiene un inconveniente que consiste en que no es posible filtrar que usuarios pueden cobrar o pagar según la cuenta financiera. Por ejemplo, si tengo un departamente que gestiona los pagos a un banco y no quiero que este departamente pueda gestionar los cobros y pagos por otro banco no tengo ninguna opción que me permita limitar por usuario/rol quien puede acceder a uno u otro. Después de reunirnos con nuestro equipo funcional diseñamos la forma de hacerlo, básicamente consistía en atar a las cuentas financieras los usuarios/roles que tendrían acceso y luego en la ventana de pagos filtrar según el criterio anterior las opciones disponibles.

Se le envió el desarrollo a un programador junior el cual al terminar su desarrollo vino a consultarme porque sólo le funcionaba en ciertas circunstancias. Su desarrollo era correcto, había utilizado la opción de regla de validación tal y como se le indicó y con eso debería funcionar pero no lo hacía. Las reglas de validación sirven para añadir opciones a la cláusula where del select que rellena un combo, de esta forma pretendíamos que sólo se mostraran las opciones de cuenta financiera disponibles para el usuario. La validación era correcta y funcionaba bien, el problema es que tras ejecutarse la select con la validación y rellenarse el combo se ejecutaba un callout (proceso que se ejecuta en el evento onblur de un campo) de otro campo y este rerellena el combo de nuevo con los valores sin filtrar. En seguida pensé que eso sería lo que estaba sucediendo y me puse a revisar los callouts de las ventanas de cobros/pagos y lo corregí. Mi solución consistía en sacar esa parte del callout y sustituirla por una validación en la definición de la referencia «table» de forma que la regla de validación estandar siguiera funcionando, al final las dos validaciones se añadirían a la cláusula where del select. Esa misma mañana tenía la solución, y por la tarde abrí un issue en Openbravo con el parche. Eso fue el 16-01-2014 y tras semanas sin respuesta, Openbravo si no pagas no suele atender los issues ni aunque le des la solución, decidimos utilizar el soporte de la versión profesional. Abrimos la incidencia en soporte oficial el día 18-02-2014 y lamentablemente a día de hoy, tras 12 días, todavía no tenemos respuesta al margen de la típica de «hemos recibido la incidencia y la vamos a atender».

En teoría lo único que tenían que hacer era revisar el parche, ver si tiene algún problema que posiblemente sí lo tenga (ellos lo pasan por su departamente de calidad en el que tienen su sistema de integración continua con sus test, etc) y aplicarlo en el core en caso de que todo hubiera ido bien. Todo este proceso no les debería haber tomado más de dos o tres días exagerando para darnos al menos una respuesta.

 

Para nosotros no es un problema porque ya lo tenemos solucionado, entonces ¿por que abrimos un issue y después una incidencia en soporte?. Pues porque nunca es buena idea mantener un fork del core para únicamente tener todos los parches que Openbravo no quiere aplicar en su versión, nos toca hacer el doble de trabajo de mantenimiento del código.

 

Esperemos que esta semana por fin nos contesten a esta y a las otras 2 incidencias que se abrieron el mismo día a las que de momento tampoco han contestado.

 

Actualización 8: Finalmente no entró en el PR14Q2, habrá que esperar 3 meses más para tener la solución de forma oficial, de momento tendremos que parchear el core por nuestra cuenta.

Actualización 7: Hoy 7 de abril, 48 días después de abrir la incidencia han empujado la corrección al control de versiones. A pesar de ello sigue planificada para el PR14Q3, esperemos que les de tiempo a que entre en el PR14Q2.

Actualización 6: Ayer 3 de abril Jon Alegría que es uno de los ingenieros de Openbravo se puso en contacto conmigo para comentarme un posible problema con mi parche. El tema era el siguiente, yo en mi parche saqué del callout la validación y la añadí en un table, el motivo de cambiar el tabledir original por un table fue justamente para poder añadir la validación sin tener que hacerlo desde una regla de validación y así dejar esta opción completamente libre para un desarrollo nuevo. Según me comentó Jon había un pequeño inconveniente, mi parche estaba bien pero la consecuencia de cambiar un tabledir por un table por lo que entiendo es que el tabledir utiliza los identificadores para rellenar el combo y el table utiliza el campo que tú le indiques más el value en caso de que exista y lo marques. En este caso querían que se mantuviera la divisa como valor a rellenar en el combo y al cambiar al table se perdía. Me preguntó que si me parecía bien que el tabledir se mantuviera y que la validación se creara como una regla de validación en lugar de en el table, el inconveniente en este caso es que el desarrollador para añadir una validación debe quitar la regla de validación del core y poner la suya, que casi por obligación debe ser idéndica a la del core y a la que le añades tu parte, técnicamente esto se conoce como hacer un fork de la validación. Los forks hay que intentar evitarlos porque hay que mantenerlos (en cada actualización del core hay que revisar que la validación no ha cambiado y si cambia actualizar tu fork en base a esta) pero bueno, en este caso podría ser una opción válida y le dije que bien, que era una opción y que si preferían hacerlo así adelante. También me dijo que intentarían empujarlo estos días para que con suerte entrara en PRQ2 🙂 . Muchas gracias por todo Jon, eres un crack.

Actualización 5: Ayer 31 de marzo replanificaron la versión en la que tendrán resuelta la incidencia original con la que abrí este apunte, ahora en lugar de liberarla en la actualización PR14Q2 (abril) la tendrán lista en el PR14Q3 (julio). Eso significa que según su planificación la incidencia estará lista y publicada unos 5 meses después de abrirla en soporte oficial, de momento llevan mes y medio.

Actualización 4: Hoy 11 de marzo, 21 días después de abrirla en soporte, han solventado una de las incidencias que básicamente consistía en aplicar un parche que les habíamos pasado para declarar dos métodos de una clase como public, esto era necesario para poder hacer personalizaciones en la contabilidad de la factura. Nos han contestado indicándonos que el parche era perfectamente correcto, que ya han hecho el commit en su mercurial y que aparecerá en una de las próximas actualizaciones. Además se han puesto en contacto con nosotros para aclarar cual era el problema en otra de las incidencias.

Actualización 3: El día 18, un mes después nos contestaron a otra de las incidencias indicándonos que ellos consideraban que ese era el comportamiento correcto y que en tal caso podría ser una nueva característica para la siguiente versión.

Actualización 2: Hoy 10 de marzo, 20 días después de abrirla en soporte, han actualizado la incidencia reasignándole el responsable.

Actualización 1: Hoy 6 de marzo por fin han contestado para disculparse por la demora y decirnos que esperan tener solucionadas las 3 incidencias a finales de semana o a principios de la semana que viene. Justo hoy hace 16 días que se abrieron estas 3 incidencias.

 

Cheli

 

Openbravo aceptó mi parche

No se si os acordáis que hace algunas semanas abrí un par de parches en Openbravo. En el primero sugerí una solución por la simplicidad de la misma, y en el segundo envié el parche. Parece ser que han corregido el primer error, eso si, con matices, y han aceptado mi parche en el segundo.

 

0020015   ,  0020038

 

El primer error consistía en que un campo «booleano» (excluir retenciones en lineas de factura) que en Openbravo se representa como un char(1) en el que únicamente se permiten valores (‘Y’, ‘N’) permitía valor null. El problema es que al utilizar el método «Copiar lineas de», ese campo se ponía a null. Mi sugerencia fué que debía restringirse el valor a (‘Y’, ‘N’) y por tanto ser not null y que al utilizar este método se pusiera a ‘N’ por defecto en lugar de a null. La respuesta de Openbravo ha sido, vale, vamos a ponerlo a ‘N’ en lugar que a null al utilizar este método pero no vamos a añadir una restricción not null porque esto rompería nuestra API (entendiendo como API que un módulo de openbravo que haya puesto a null el valor de este campo incorrectamente igual que lo hacía el «Crear lineas de» se rompería al aplicar el cambio.

 

En el segundo error envié el parche, y este parece que lo han aceptado. Consistía en que no se calculaban los campos de base imponible para impuestos y impuestos en lineas de factura cuando se utilizaba la función «Crear lineas de». Lo que hice es que se aplicara el mismo cálculo de estos dos campos al ejecutar el proceso «Crear lineas de» que cuando se guardaba una linea de factura.

 

Estoy contento porque como ya comenté en mi anterior apunte Openbravo no suele aceptar correcciones o parches que no vengan de Partnes (que pagan). Yo estoy en contra de las políticas que ha tomado la emrpesa (empresa con modelo de negocio privativo con licencia del core libre para aparentar) y que creo que la están hundiendo. Pero bueno, esto demuestra que aceptan cosas externas y es de agradecer, ¿quizá se estén dando cuenta de su error?, error desde mi punto de vista claro.

 

Cheli

Parche Vtiger CRM, informe de proveedores

En uno de los proyectos en Tictech he tenido que parchear vtiger para poder sacar informes de proveedores desde el asistente. Para aplicar el parche simplemente copia el archivo vtiger-proveedores-5.0.4.tar.bz2 al raiz de vtiger y descomprime y desmpaqueta el archivo, automáticamente sobreescribirá los dos archivos modificados y ya te aparecerá la opción de crear el informe de proveedores desde el asistente.

Este parche sólo está probado en la versión 5.0.4, seguramente es muy mejorable así que si veis algún error por favor notificarmelo.

Este parche se distribuye bajo la misma licencia que Vtiger, la VPL basada en la MPL.

Cheli