Re: [Health-es] Problemas en desarrollo

[Luis González]

Hola Oscar:

El 30/8/14, Oscar Alvarez <address@hidden> escribió:
> No es necesario desarrollar todo un modulo para cambiar un reporte,
> simplemente
> vas a administración, interfaz, accciones, informes y borras el informe
> que quieres cambiar en el campo
> que relaciona el binario del archivo y lo reemplazas por el tuyo.
>
> En el peor de los casos basta con reemplazar en el modulo health el .odt
> original y sobreescribirlo con el nuevo, tan simple como eso.

Según me han explicado en esta misma lista, la forma correcta de hacer
modificaciones no es modificar el módulo Health directamente, sino
crear un módulo nuevo que realice las modificaciones necesarias. ¿Qué
pasaría si en un futuro quisiera actualizar el módulo Health? No
podría hacerlo sin perder todas las modificaciones que haya hecho; y
tendría que hacerlas de nuevo. Por otro lado, el módulo no solo
modifica reportes, realiza diversas ,modificaciones a varios módulos.

> El campo "active" mencionado en la documentacion puede ser un error ya
> que no existe en la db ni en el modelo de datos.

Es posible, pero creo que no, porque lo admite la sintaxis XML.

> Tryton 3.2 te dice que palabra esta duplicada eso deberia ser suficiente
> para que vayas a la DB y la borres, usando filtros con pgAdmin.

No lo dice, ese es el problema. Como prueba, pongo el error que me da:
--------------------------------------------------------------------------------
Traceback (most recent call last):
  File "./trytond", line 113, in <module>
    trytond.server.TrytonServer(options).run()
  File "/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/server.py",
line 123, in run
    Pool(db_name).init(update=update, lang=lang)
  File "/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/pool.py",
line 151, in init
    lang=lang)
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/modules/__init__.py",
line 429, in load_modules
    _load_modules()
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/modules/__init__.py",
line 397, in _load_modules
    load_module_graph(graph, pool, lang)
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/modules/__init__.py",
line 264, in load_module_graph
    Translation.translation_import(lang2, module, filename)
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/ir/translation.py",
line 904, in translation_import
    translations |= set(cls.create(to_create))
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/ir/translation.py",
line 727, in create
    return super(Translation, cls).create(vlist)
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/model/modelsql.py",
line 459, in create
    cls.__raise_integrity_error(exception, values)
  File 
"/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/model/modelsql.py",
line 232, in __raise_integrity_error
    cls.raise_user_error(error)
  File "/var/lib/gnuhealth/tryton/server/trytond-3.2.2/trytond/error.py",
line 74, in raise_user_error
    raise UserError(error)
trytond.exceptions.UserError: ('UserError', ('Translation must be unique', ''))
--------------------------------------------------------------------------------

Como se puede observar, sólo dice "Translation must be unique", no
informa cual es el término duplicado ni en que línea está.

> Para que poner de nuevo de la entrada duplicada si ya se sabe que genera
> error?

Por dos razones:
1. Sabía que el duplicado estaba en ese grupo de 5, pero no sabía cual
era; así que lo colocaba de nuevo 1 por 1 para ver si fallaba. Si
llegaba a fallar, eso me diría que ese era el término duplicado. Es
muy común en programación probar a quitar y poner líneas para observar
el comportamiento resultante y diagnosticar problemas.

2. Para probar que se pueden añadir duplicados inadvertidamente, que
no fallará hasta que se coloque en una instalación nueva.

> En general Tryton no es muy tolerante con los errores de los
> desarrolladores, y eso es bueno.

Al contrario, es muy tolerante con los errores, porque te permite
tener errores sin darte cuenta. Y eso no es bueno para un
desarrollador, porque si no sabes en donde está un error (o ni
siquiera sabes que existe) es poco probable que lo puedas corregir.

-- 
Salu2
Luis F. González V.