openerp-l10n-ar-localization team mailing list archive

[Cristian Sebastian Rocha <cristian.rocha@xxxxxxxxxxx>]

Otro tema que surge,

La utilización de metadata en los archivos del módulo. Ignacio agregó:

__author__ = "López Ignacio M. (www.dinamotion.com.ar) - lopezignacio@xxxxxxxxx"

aquí hay dos temas.

1ro) El módulo lo inicié yo, con lo que Ignacio estaría eliminando mis
créditos. Yo se que no lo hizo con mala fe, como cualquier otro que
modifique el módulo creo que se va a tentar a hacer lo mismo.

2do) En este tipo de addons no tiene sentido usar metadata de en los
archivos fuentes. Estos datos deberían solo aparecer en el
__openerp__.py

El problema con el __openerp__.py es que no acepta varios autores. Con
el merge que intenté realizar hace tiempo asociado a la autoría yo
proponía lo siguiente:

"El autor" de todos los módulos de la localización es "Team de
Localización Argentina"

Y los autores o modificadores de los módulos deberían ir al archivo AUTHORS.

Opiniones, please.

2012/10/1 Cristian Sebastian Rocha <cristian.rocha@xxxxxxxxxxx>:
> Gente,
>
> encontré otro detalle, que dirán que boludes, pero me parece muy importante.
>
> Según la GNU General Public License v3.0, Sección "How to Apply These
> Terms to Your New Programs", los encabezados de los códigos
> recomiendan que tengan la siguiente estructura:
>
>     <one line to give the program's name and a brief idea of what it does.>
>     Copyright (C) <year>  <name of author>
>
>     This program is free software: you can redistribute it and/or modify
>     it under the terms of the GNU General Public License as published by
>     the Free Software Foundation, either version 3 of the License, or
>     (at your option) any later version.
>
>     This program is distributed in the hope that it will be useful,
>     but WITHOUT ANY WARRANTY; without even the implied warranty of
>     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>     GNU General Public License for more details.
>
>     You should have received a copy of the GNU General Public License
>     along with this program.  If not, see <http://www.gnu.org/licenses/>.
>
> Pero Ignacio la cambió un poquito. En vez de poner solo el año del
> copyright puso un rango de años. Para tener la menor cantidad de
> problemas de licencias voy a cambiar esos encabezados a lo recomendado
> por la licencia GPL. Por favor, mantengan ese encabezado sin
> modificaciones.
>
> Otra... yo tengo un vicio y pido permiso por ello. Yo edito con VIM
> (www.vim.org) y una forma fácil de manter la estructura de los
> archivos python es agregarle un comentario que permite configurar ese
> editor de forma diferente por archivo. Ese encabezado es:
>
> # vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4:
>
> Como ven, el python lo entiende como un comentario, por lo que no
> debería afectarles a nadie. Les agradecería que todos voten a favor a
> dejar ese comentario :) Please! Por los usuarios y amantes del Vi.
>
> 2012/10/1 Cristian Sebastian Rocha <cristian.rocha@xxxxxxxxxxx>:
>> Hola Ignacio,
>>
>> estoy mergiando tu código y me encontré con algunos detalles que me
>> gustaría discutir con vos:
>>
>> 1) vat en el objeto re.bank
>>
>> No hay ninguna parte de OpenERP que utilice vat excepto cuando
>> correponde a un objeto res.partner. Si uno quisiera aprovechar esa
>> información debería modificar mucho código. Yo llamaría ese tipo de
>> columnas como columnas huerfanas, columnas que ningún código tiene
>> pensado utilizar, y trataría de evitarlas todo lo posible.
>>
>> Pero seguro que en algún caso este dato puede ser útil. Cúando? Cuando
>> queremos ser clientes o proveedores del banco. En el caso seguro que
>> somos clientes, por lo tanto debería ir a la lista de clientes, no
>> solo a la lista de bancos.
>>
>> Lo que me gustaría que ocurra es que el banco esté asociado a un
>> partner, y que ese parter tenga el dato del VAT, así cuando generamos
>> facturas de proveedor podemos asociar el banco rápidamente. Que
>> opinas?
>>
>> 2) Campo update.
>>
>> Este campo va a ser un problema. Como te comenté en su momento,
>> OpenERP trabaja con el campo 'active' para determinar si el objeto
>> está activo o no (addons/base/res/bank.py). Yo preferiría trabajar con
>> él y no con algo nuevo, porque la base de datos de OpenERP no está
>> pensada como OLAP, sino como transaccional. A la hora de hacer un
>> update desactivaría todos los bancos y luego la activaría de nuevo. Lo
>> que si, hay que definir una clave primaria a la tabla de bancos para
>> no repetirlos en el caso que no exista ningún update.
>>
>> En el caso de querer utilizar un campo tipo 'update' creo que primero
>> deberías leer el siguiente artículo:
>> http://en.wikipedia.org/wiki/Slowly_changing_dimension
>>
>> Eso por ahora.
>>
>> Abrazo,
>> Cristian.