Openbravo resuelve un nuevo bug de los que les he reportado

Esta vez no tardaron tanto en resolverlo, sólo un par de meses. El caso era que en el último proyecto en el que he estado trabajando teníamos que migrar unos módulos de la versión 2.50 a la versión 3.0. En dicha migración me di cuenta que unas vistas que estaban en base de datos pero no modularizadas no se podían exportar ya que se utilizaban funciones de postgresql que devolvían «double precision». Tal era el problema que incluso haciendo casting se exportaba incorrectamente y en consecuencia era imposible volver a importar la vista.

La solución momentánea pasó por un hack guarrete pero que funcionaba, concatenaba el double precision con una cadena vacía de forma que todo en consecuencia pasaba a ser una cadena (cast implícito) y a este le aplicaba la función TO_NUMBER de Openbravo, algo como esto.

 

TO_NUMBER(date_part(…) || »)

 

Openbravo ahora lo ha solucionado según indican en el issue que abrí, parece que era lo suficientemente grave como para solucionar mi problema a pesar de no ser partner.

 

Cheli

Correo-e inesperado de Openbravo

El otro día os contaba que Openbravo me había aceptado un parche, pues esta tarde he recibido un correo-e de Eduardo Argal, empleado de Openbravo, relacionado con el mismo. El correo-e es el siguiente.

 

Hola Cheli,

Te escribo para darte las gracias por el patch adjunto al issue «20038: Create Lines From in Sales invoices doesn’t set taxamt and taxbaseamt fields properly».
Nos gustaría incluir el patch que tu adjuntas en el issue, pero como política interna necesitamos que firmes y nos envies una copia del siguiente documento:

http://wiki.openbravo.com/wiki/Contributor%27s_Guide#Legal_aspects

Se trata de un documento que cualquier contributor debe de firmar antes de que podamos publicar su código como parte de la distribución core de Openbravo ERP.

Espero tu respuesta, y gracias de nuevo por la contribución.


Atentamente,

Eduardo Argal

 

Lo que me pide es que ceda mis derecho de copia a Openbravo para integrar el parche dentro del core. Es una práctica muy extendida entre las empresas que desarrollan un producto con licencia libre, lo que quieren es seguir teniendo el control sobre el código y poder hacer cosas como relicenciarlo. Esto en principio no es malo pero podría suceder que Openbravo en algún momento relicenciara el core con una licencia privativa y que tu parche estuviera en ese código.

A mi esta política no me gusta e intento evitarla en lo posible, entonces ¿por qué voy a acceder a firmar el documento?. Pues porque este parche a mi ni me va ni me viene, corrige un bug en el core que hacía que uno de los desarrollos que hice para un cliente no funcionara correctamente en un caso concreto, cuando se utilizaba el botón «Copiar lineas de». Además si no se corrige y se integra en el core me va a tocar seguir manteniendo el fork que tuve que crear con mi parche y no quiero dedicar tiempo a eso, simplemente no me interesa.

 

Lo gracioso del tema es que después de todos los problemas que he tenido con la empresa Openbravo al final va a haber un pedacito de código mio en su core :D.

 

Cheli