Re: [tryton-dev] mercurial-server migration
Hi, On 15.12.2014 23:47, Cédric Krier wrote: Hi, I started to work on migrate the current infrastructure of mercurial repositories to mercurial-server. I have some questions about the transition where we could solve some issue. - I'm thinking about removing the subfolder modules/ to put all modules on top level. Because of the hgnested, we can not ask hgwebdir to show all subdirectories otherwise all modules will be duplicated under trytond/, so we don't see currently the modules directly, that's why I propose to move all modules under /. It will break all repository that point to the old path. For now it was quite simple to clone all modules as in they are separated. As we are working on older versions we cannot use hgnested any more since the usage of branches. I would really miss the current structure as i only see the solution to manage a list of repos that are not modules and to skip them when i want to clone all modules without hgnested. - I'm also thinking about removing old redirection from series to root like 3.0 - / +1 Once the migration will be done, committers and translators will have access using this paths: ssh://h...@hg.tryton.org/trytond I already copied all the ssh keys but the idea will be to store them in the roundup user profile. When I will do the migration, I espect to have a downtime of hg.tryton.org for few hours. I will drop an email here on start and end.
Re: [tryton-dev] mercurial-server migration
On 19 Dec 12:15, Korbinian Preisler wrote: Hi, On 15.12.2014 23:47, Cédric Krier wrote: Hi, I started to work on migrate the current infrastructure of mercurial repositories to mercurial-server. I have some questions about the transition where we could solve some issue. - I'm thinking about removing the subfolder modules/ to put all modules on top level. Because of the hgnested, we can not ask hgwebdir to show all subdirectories otherwise all modules will be duplicated under trytond/, so we don't see currently the modules directly, that's why I propose to move all modules under /. It will break all repository that point to the old path. For now it was quite simple to clone all modules as in they are separated. OK, let's keep it like that. I find a way to put on the index page a small table with the repository layout see http://hg.tryton.org/ As we are working on older versions we cannot use hgnested any more since the usage of branches. I would really miss the current structure as i only see the solution to manage a list of repos that are not modules and to skip them when i want to clone all modules without hgnested. I think we could create shared repositories for each series with only the subset of modules that haves the branch. I will try this when migrating the repository structure (probably this WE). -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
Re: [tryton-dev] RFC: Report Refactorization
On 19 Dec 19:30, Nicolas Évrard wrote: Hello, Last week I took some time to change a bit the API of the Report object. There has always been a need some part of this API that I did not like eg: I had the impression that the separation between the data processing part and the rendering part was not clearly defined. So I took a peak at the re-implementation of the Report to support html templating with webkit or pisa (from OpenLabs and Grasbauer respectively) and also the JasperReport implementation from NaNtiC. In the end here is the review: http://codereview.tryton.org/8831002/ So I added those methods: - get_localcontext: it should be used to make the data processing part. In theory our modules should only override this method Do we need to keep the name localcontext? Maybe it is also the time to remove most of the default values set. And also refactor and rename formatLang because it is also an odd code. - render_report: which is the method that leverage the report engine to create the report data Why not just 'render'? - test_postprocess: Test whether or not the report data should be postprocessed (think about odt - doc or html - pdf) Why do we need a test_postprocess? We could call postprocess always and if nothing needs to be done, it does nothing. - postprocess: Make the necessary calls to postprocess the data (calling unoconv, pisa, …) Maybe 'convert' is a better name. We could also remove compatibility from very old relatorio version. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgpqOlIkqPkjo.pgp Description: PGP signature
Re: [tryton-es] Duda respecto Sale Device en módulo sale_shop
Hola Maria Cecilia, On 19/12/14 11:37, Maria Cecilia Santos Popper wrote: Hola! Tengo una duda respecto de esta opción en el módulo sale_shop. Lo que estoy queriendo lograr es generar dos devices (dispositivos) distintos para registrar los pagos: un para pagos en efectivo y el otro para pagos con tarjetas. He generado los dos extractos (Caja y Tarjetas, respectivamente. Ambos están abiertos en estado borrador. Pero al querer hacer un pago de una venta ficticia, cuando selecciono el boton pagar, sólo me aparece el extracto Caja. Lo mismo sucede cuando quiero abrir los Statements desde la opción que aparece en el módulo ventas. Lo que noto es que en la pestaña Preferencias del usuario al cual le he asignado el shop, sólo puedo seleccionar un tipo de Sale Device, por lo que es lógico que luego no pueda seleccionarlo al momento de pagar la venta. La pregunta es: hay alguna forma de seleccionar múltiples devices para un mismo usuario??? Gracias y espero que no sea muy tonta mi pregunta. El módulo sale_shop solo proporciona tiendas, supongo que te refieres al sale_payment que añade devices (dispositivos) y los relaciona con extractos. No está diseñado para ser configurado como expones. Los devices (dispositivos) son los terminales de venta TPV y cada uno de ellos puede tener formas de pago distintas configurados como diarios de extracto. En tu caso tienes un device y dos diarios de extracto (payment journals). En la presentación [1] que hice en el TUB2013 lo tienes brevemente expuesto. [1] http://downloads.tryton.org/TUB2013/pos.pdf -- Jordi Esteve Consultor Zikzakmedia SL jest...@zikzakmedia.com Mòbil 679 170 693 Zikzakmedia SL St. Jaume, 9, baixos, 2a 08720 Vilafranca del Penedès Tel 93 890 2108
Re: [tryton-es] Duda respecto Sale Device en módulo sale_shop
Gracias Jordi! Entiendo ahora como configurarlo. Y gracias también a Luis Deiana que me ayudó también! 2014-12-19 9:14 GMT-03:00 Jordi Esteve jest...@zikzakmedia.com: Hola Maria Cecilia, On 19/12/14 11:37, Maria Cecilia Santos Popper wrote: Hola! Tengo una duda respecto de esta opción en el módulo sale_shop. Lo que estoy queriendo lograr es generar dos devices (dispositivos) distintos para registrar los pagos: un para pagos en efectivo y el otro para pagos con tarjetas. He generado los dos extractos (Caja y Tarjetas, respectivamente. Ambos están abiertos en estado borrador. Pero al querer hacer un pago de una venta ficticia, cuando selecciono el boton pagar, sólo me aparece el extracto Caja. Lo mismo sucede cuando quiero abrir los Statements desde la opción que aparece en el módulo ventas. Lo que noto es que en la pestaña Preferencias del usuario al cual le he asignado el shop, sólo puedo seleccionar un tipo de Sale Device, por lo que es lógico que luego no pueda seleccionarlo al momento de pagar la venta. La pregunta es: hay alguna forma de seleccionar múltiples devices para un mismo usuario??? Gracias y espero que no sea muy tonta mi pregunta. El módulo sale_shop solo proporciona tiendas, supongo que te refieres al sale_payment que añade devices (dispositivos) y los relaciona con extractos. No está diseñado para ser configurado como expones. Los devices (dispositivos) son los terminales de venta TPV y cada uno de ellos puede tener formas de pago distintas configurados como diarios de extracto. En tu caso tienes un device y dos diarios de extracto (payment journals). En la presentación [1] que hice en el TUB2013 lo tienes brevemente expuesto. [1] http://downloads.tryton.org/TUB2013/pos.pdf -- Jordi Esteve Consultor Zikzakmedia SL jest...@zikzakmedia.com Mòbil 679 170 693 Zikzakmedia SL St. Jaume, 9, baixos, 2a 08720 Vilafranca del Penedès Tel 93 890 2108 -- Lic. Cecilia Santos Popper Santa Fe (0342) 154 440 615 www.linkedin.com/in/ceciliasp/
Re: [tryton] RfC: maning of new state of stock move
* Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 19 Dec 2014 11:56:57 +0100): On 05 Dec 11:57, Mathias Behrle wrote: Hi all, I would like to pull a little bit of your attention to the following issue: For [1] there is coming a new state for stock moves, for which the current proposal [2] is 'None'. My point of view is: there shouldn't be a state of None. As soon as an object has a state, it has one and 'None' is misleading. This is different from selections, where you can can make a selection or not. I proposed several alternatives: 'Preliminary', 'Preparative', 'Provisional', 'Tentative' What would be your prefered name just in case? I propose 'Staging' as refering in https://en.wikipedia.org/wiki/Staging_%28data%29 Yes, even better, sounds good to me. -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgprHYgcJfh1m.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RfC: maning of new state of stock move
* Mathias Behrle [2014-12-19 12:26 +0100]: * Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 19 Dec 2014 11:56:57 +0100): On 05 Dec 11:57, Mathias Behrle wrote: Hi all, I would like to pull a little bit of your attention to the following issue: For [1] there is coming a new state for stock moves, for which the current proposal [2] is 'None'. My point of view is: there shouldn't be a state of None. As soon as an object has a state, it has one and 'None' is misleading. This is different from selections, where you can can make a selection or not. I proposed several alternatives: 'Preliminary', 'Preparative', 'Provisional', 'Tentative' What would be your prefered name just in case? I propose 'Staging' as refering in https://en.wikipedia.org/wiki/Staging_%28data%29 Yes, even better, sounds good to me. I second that proposition. -- Nicolas Évrard - B2CK SPRL E-mail/Jabber: nicolas.evr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ signature.asc Description: Digital signature
