Re: [Openerp-community] General problems with datetime fields and time zones...
On 2014-09-22 05:38, Mario Arias wrote: what I was trying to say: if a user with time zone New York and another with Paris in their odoo profile calls the same report for July 2014 it must return the same data so if the period_id is stored in the data it's easy. probably this is what context_today does. Hi Ferdinand, Problem is that any period that you define will suffer the same problem. Datetimes at the very begining or end of any given period will be placed in wrong one, accordingly to the timezone of the user and impact is bigger as the timezone difference increases How can you explain a customer that their reports are not accurate because Odoo must support companies with multiple time zones ? They should be accurate for companies in a single time zone, and from there move to work for multi time zone ones... Right now, it is not working for any of them, unless your clients are in Europe... Again, if Odoo displays datetime fields adjusted to user time zone, then filters on datetime should be adjusted accordingly... Then, defaults for date and datetime should be checked, to see if time.strftime is correct or should be changed to context_today calls (most calls should use the later... ) And finally, reports should be adjusted to use formatLang instead of plain datetime fields... Regards, -Mario On Sun, Sep 21, 2014 at 11:01 AM, Ferdinand Gassauer off...@chricar.at mailto:off...@chricar.at wrote: On 2014-09-21 04:35, Mario Arias wrote: My suggestion is to use periods (or weeks, trimester, fiscal years,...) for search. (only rare cases use the DAY as search criteria) odoo must guarantee that users in different time zones product the same results if not - Odoo can't be used in multi-timezone companies (or even switching to/from daylight saving may return different results around midnight) At display time, Odoo is translating all datetime fields to user timezone. The same should be true for filters... but it isn't. If we fix them, we would have covered a lot of current problems. Most others are just result of bad programming or old traces of code when datetimes were not in UTC, and them could be identified easily with a search in the code, like most (all??) time.strftime calls that should be replaced by fields.date.context_today, as the ORM/web client will translate them to UTC when saving to database... Same for reports, as all datetime fields should use formatLang to take care of time zone issues... All defaults for Date only fields should also be checked, as sometimes they are registered on next day or previous day relative to user that is creating the records, and that is legally wrong, besides messing up any reporting... I can go ahead and create a mega issue report with all wrong occurrences, or even go one by one... but at least would like to hear someone from S.A. confirming that is the way to go and that they will check, as so far this doesn't seem to be the case with most issues on this still open... Regards, -Mario On Sat, Sep 20, 2014 at 5:32 PM, Pedro Manuel Baeza Romero pedro.ba...@gmail.com mailto:pedro.ba...@gmail.com wrote: Hi, Mario, I agree that tz issues is a question to solve, but I don't think this is very easy to handle or do it in a general way, because you can't set a general rule to apply when something must be treated on UTC or in the user tz. There is another technical question I see now in one of the issues you comment: information on pivot tables (BI reports) are taken directly from the DB (for performance reason), without no possibility of modifying some things like these dates, that are saved on UTC format. We can anyway contribute with fixes to each localized issue that can be solved to speed up the process of removing them. Regards. 2014-09-21 1:24 GMT+02:00 Mario Arias the.clone.mas...@gmail.com mailto:the.clone.mas...@gmail.com: If you check githut or LP, you will find a many issues reported about time zone problems, and most of them are not solved, as a quick search on github shows... https://github.com/odoo/odoo/issues/2482 https://github.com/odoo/odoo/issues/2199 https://github.com/odoo/odoo/issues/2115 https://github.com/odoo/odoo/issues/1897 https://github.com/odoo/odoo/issues/1349 https://github.com/odoo/odoo/issues/822 https://github.com/odoo/odoo/issues/1108. . . . If we keep trying to fix those as isolated issues, we will never finish... We need to address this at the ORM / web server level... On Fri, Sep 19, 2014 at 6:02 PM, Mario Arias
Re: [Openerp-community] Webkit Reports future...
On 21/09/2014 17:02, Lionel Sausin wrote: Hi, The situation here is : - merge proposal for report_webkit have been ignored by the RD team until after 7.0 - RD now accepts pull requests more willingly, but 8.0 is frozen so no feature will go in - pull requests for master will also be refused because report_wekbit is removed - OCA's backport branch OCB won't help us either because, since the features are refused in master, they would not be backports but new features. So, it's a bit absurd but I'm afraid we're deadlocked until at least v9 is released. Unless maybe OCA can make an exception by accepting new features for deprecated modules? Lionel I'm not willing to do that, because I'm concerned we will get issues with some addons breaking with OCB / Official and not with the other one. The proper way of handling this would be to propose an *addon* to OCA adding the papersize feature / report with no margin. Then you can install that addon or not, depending on your needs, and not break anything. -- Alexandre Fayolle Chef de Projet Tel : + 33 (0)4 79 26 57 94 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
[Openerp-community] Webkit Reports (and other deprecated modules) future
Le 22/09/2014 08:58, Alexandre Fayolle a écrit : The proper way of handling this would be to propose an *addon* to OCA adding the papersize feature / report with no margin. We tried that and it's a mess too. The original code is not modular, so that makes big chunks of copy-paste for every 2 line patches, and the modules won't even be compatible with each other. So I see no other choice but to fork (and it's OK too). I can see 3 ways we can do it: 1/ each of us maintains his own branch until after v9 (current situation) 2/ we share a single module called report_webkit_community that will host a complete copy/paste of the official module, and which replaces all the standard objects at runtime (inherit without calling super() ) 3/ we make a feature-branch to host all our patches - those who want to use it can merge it on their own instance. If hosted by OCA, it could be be something like OCB/7.0-feature-base_report_webkit. Would OCA be willing to bear the burden of reviewing PRs on this branch - and the probable others regarding document_ftp, project_long_term, ... ? Then OCB would become Odoo Comunity Branches :) Lionel. ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Webkit Reports (and other deprecated modules) future
I'm voting for option 3 as we may think that bug fixes will still be merged on v8 so for feature modules AFAIK is the way we already do. 2014-09-22 9:47 GMT+02:00 Lionel Sausin l...@numerigraphe.com: Le 22/09/2014 08:58, Alexandre Fayolle a écrit : The proper way of handling this would be to propose an *addon* to OCA adding the papersize feature / report with no margin. We tried that and it's a mess too. The original code is not modular, so that makes big chunks of copy-paste for every 2 line patches, and the modules won't even be compatible with each other. So I see no other choice but to fork (and it's OK too). I can see 3 ways we can do it: 1/ each of us maintains his own branch until after v9 (current situation) 2/ we share a single module called report_webkit_community that will host a complete copy/paste of the official module, and which replaces all the standard objects at runtime (inherit without calling super() ) 3/ we make a feature-branch to host all our patches - those who want to use it can merge it on their own instance. If hosted by OCA, it could be be something like OCB/7.0-feature-base_report_webkit. Would OCA be willing to bear the burden of reviewing PRs on this branch - and the probable others regarding document_ftp, project_long_term, ... ? Then OCB would become Odoo Comunity Branches :) Lionel. ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Webkit Reports (and other deprecated modules) future
Hi Lionel, we also have this papersize problem on one project. Just want to print label from label printer. And i totally agree sometime a new module is nice. But some time it mean you have copypaste of the original module, than you can make better a fork. So in this case the no new feature to stable policy is stupid. In this case not all parameter of webkit are not supported from the python class. Adding this breaks nothing, has no risk for other installation but make the live easy for the few people needing it. I m not happy to maintain my own branch but at the moment OpenERP S.A. force it. Markus On 22.09.2014 09:47, Lionel Sausin wrote: Le 22/09/2014 08:58, Alexandre Fayolle a écrit : The proper way of handling this would be to propose an *addon* to OCA adding the papersize feature / report with no margin. We tried that and it's a mess too. The original code is not modular, so that makes big chunks of copy-paste for every 2 line patches, and the modules won't even be compatible with each other. So I see no other choice but to fork (and it's OK too). I can see 3 ways we can do it: 1/ each of us maintains his own branch until after v9 (current situation) 2/ we share a single module called report_webkit_community that will host a complete copy/paste of the official module, and which replaces all the standard objects at runtime (inherit without calling super() ) 3/ we make a feature-branch to host all our patches - those who want to use it can merge it on their own instance. If hosted by OCA, it could be be something like OCB/7.0-feature-base_report_webkit. Would OCA be willing to bear the burden of reviewing PRs on this branch - and the probable others regarding document_ftp, project_long_term, ... ? Then OCB would become Odoo Comunity Branches :) Lionel. ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp -- Dipl.-Comp.-Math. Markus Schneider Softwareentwickler initOS GmbH Co. KG An der Eisenbahn 1 21224 Rosengarten Mobil: +49 (0)172 2303699 Phone: +49 (0)4105 5615613 Fax: +49 (0)4105 5615610 Email: markus.schnei...@initos.com Web: http://www.initos.com Geschäftsführung: Dipl. Wirt.-Inf. Frederik Kramer Dipl.-Ing. (FH) Torsten Francke Haftende Gesellschafterin: initOS Verwaltungs GmbH Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRA 201840 USt-IdNr: DE 275698169 Steuer-Nr: 15/205/21402 ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
[Openerp-community] OCA Intrastat proposal
Hi OCA members! I think that will be very nice to build a intrastate project and insert in the OCA Localizations the reports and the exports modules that Akretion have mades. https://code.launchpad.net/~new-report-intrastat-team/new-report-intrastat/trunk A question: i possible to integrate the base_intrastat with the core report_intrastat of odoo? The module description told that the two module isn't compatible, but is possible to make it compatible or is radically different? Regards -- Franco Tampieri System Engineer _ abstract.it - +39 06 9294 6938 Registro Imprese di Napoli 788429 / Cap. Soc. 10.000 Euro I.V. Avvertenze Legali – D. Lgs. 196/03 Tutela dei dati personali. Le informazioni contenute in questo messaggio e in ogni eventuale allegato sono riservate e ne è vietata ogni forma di diffusione. Se avete ricevuto questa comunicazione per errore, Vi preghiamo di informare immediatamente il mittente del messaggio e di eliminare l'e-mail. ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Webkit Reports future...
On 21/09/2014 17:02, Lionel Sausin wrote: Hi, The situation here is : - merge proposal for report_webkit have been ignored by the RD team until after 7.0 - RD now accepts pull requests more willingly, but 8.0 is frozen so no feature will go in - pull requests for master will also be refused because report_wekbit is removed - OCA's backport branch OCB won't help us either because, since the features are refused in master, they would not be backports but new features. I've thought about this a bit more, and I think, given the nature of the changes which are mentioned in the 2 original PR, this could make it to OCB. The rules are a bit hazy here, and certainly less strict than the ones in official odoo. We do have some changes in there which were later rejected in official... I suggest you push a PR on the OCB branches, where they will be examined and discussed (and eventually accepted or rejected). It will certainly cost less than maintaining your own fork. -- Alexandre Fayolle Chef de Projet Tel : + 33 (0)4 79 26 57 94 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] General problems with datetime fields and time zones...
Yes, and that is why odoo uses in some places fields of type date. That, together with a good default value from context_today, will ensure that reports are consistent. Problem is that in most places, there are only datetime fields, or date fields that default to time.strftime (not considering creator user's timezone), and that breaks consistency. You find this in POS, events, HR, ... So we have two cases: - A multi time zone company, that needs ALL reporting that does grouping by date to use DATE only fields fro grouping/filtering. - A single time zone company, that only needs consistent adjustment of datetime fields AND filters across views and reports... I am sure that a big majority of Odoo users belong to second option. Besides, adding date only fields to models with problems is not an option under stable no model change policy, so I guess the only option we have for v7 or v8 is fixing filtering to consider user timezone, and create extra modules to fix problems to our clients that belong to case 1... Maybe for v9 Odoo could add date fields, so case 1 finally works out of the box... Regards, -Mario On Mon, Sep 22, 2014 at 12:22 AM, Ferdinand Gassauer off...@chricar.at wrote: On 2014-09-22 05:38, Mario Arias wrote: what I was trying to say: if a user with time zone New York and another with Paris in their odoo profile calls the same report for July 2014 it must return the same data so if the period_id is stored in the data it's easy. probably this is what context_today does. Hi Ferdinand, Problem is that any period that you define will suffer the same problem. Datetimes at the very begining or end of any given period will be placed in wrong one, accordingly to the timezone of the user and impact is bigger as the timezone difference increases How can you explain a customer that their reports are not accurate because Odoo must support companies with multiple time zones ? They should be accurate for companies in a single time zone, and from there move to work for multi time zone ones... Right now, it is not working for any of them, unless your clients are in Europe... Again, if Odoo displays datetime fields adjusted to user time zone, then filters on datetime should be adjusted accordingly... Then, defaults for date and datetime should be checked, to see if time.strftime is correct or should be changed to context_today calls (most calls should use the later... ) And finally, reports should be adjusted to use formatLang instead of plain datetime fields... Regards, -Mario On Sun, Sep 21, 2014 at 11:01 AM, Ferdinand Gassauer off...@chricar.at wrote: On 2014-09-21 04:35, Mario Arias wrote: My suggestion is to use periods (or weeks, trimester, fiscal years,...) for search. (only rare cases use the DAY as search criteria) odoo must guarantee that users in different time zones product the same results if not - Odoo can't be used in multi-timezone companies (or even switching to/from daylight saving may return different results around midnight) At display time, Odoo is translating all datetime fields to user timezone. The same should be true for filters... but it isn't. If we fix them, we would have covered a lot of current problems. Most others are just result of bad programming or old traces of code when datetimes were not in UTC, and them could be identified easily with a search in the code, like most (all??) time.strftime calls that should be replaced by fields.date.context_today, as the ORM/web client will translate them to UTC when saving to database... Same for reports, as all datetime fields should use formatLang to take care of time zone issues... All defaults for Date only fields should also be checked, as sometimes they are registered on next day or previous day relative to user that is creating the records, and that is legally wrong, besides messing up any reporting... I can go ahead and create a mega issue report with all wrong occurrences, or even go one by one... but at least would like to hear someone from S.A. confirming that is the way to go and that they will check, as so far this doesn't seem to be the case with most issues on this still open... Regards, -Mario On Sat, Sep 20, 2014 at 5:32 PM, Pedro Manuel Baeza Romero pedro.ba...@gmail.com wrote: Hi, Mario, I agree that tz issues is a question to solve, but I don't think this is very easy to handle or do it in a general way, because you can't set a general rule to apply when something must be treated on UTC or in the user tz. There is another technical question I see now in one of the issues you comment: information on pivot tables (BI reports) are taken directly from the DB (for performance reason), without no possibility of modifying some things like these dates, that are saved on UTC format. We can anyway contribute with fixes to each localized issue that can be solved to speed up the
Re: [Openerp-community] Webkit Reports future...
At least for the zero margins one, reason for rejection was that this would break existing reports for templates that are relying on defaults... This can be fixed by running a one time update to current templates, replacing 0 with actual defaults from wkhtmltopdf... Problem is that a module update could eventually restore values to 0 for there templates... How could this be included in the PR ? Regards, -Mario On Mon, Sep 22, 2014 at 7:53 AM, Alexandre Fayolle alexandre.fayo...@camptocamp.com wrote: On 21/09/2014 17:02, Lionel Sausin wrote: Hi, The situation here is : - merge proposal for report_webkit have been ignored by the RD team until after 7.0 - RD now accepts pull requests more willingly, but 8.0 is frozen so no feature will go in - pull requests for master will also be refused because report_wekbit is removed - OCA's backport branch OCB won't help us either because, since the features are refused in master, they would not be backports but new features. I've thought about this a bit more, and I think, given the nature of the changes which are mentioned in the 2 original PR, this could make it to OCB. The rules are a bit hazy here, and certainly less strict than the ones in official odoo. We do have some changes in there which were later rejected in official... I suggest you push a PR on the OCB branches, where they will be examined and discussed (and eventually accepted or rejected). It will certainly cost less than maintaining your own fork. -- Alexandre Fayolle Chef de Projet Tel : + 33 (0)4 79 26 57 94 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedexhttp://www.camptocamp.com ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Webkit Reports future...
On Mon, Sep 22, 2014 at 8:52 AM, Alexandre Fayolle alexandre.fayo...@camptocamp.com wrote: maybe a migration script ensuring the changing of defaults? Or maybe you could have a checkbox saying 'use 0cm margin'? I guess second option is safer, as eventually we will not know if a report really wants 0 margins or is expecting defaults... Reports that really want this new feature will opt-in... Unless there is a better suggestion, will go this route on the PR. Regards, -Mario ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Project Management
Hello Guys, Any help will be appreciated On Fri, Sep 19, 2014 at 5:06 PM, pankaj dev pankajde...@gmail.com wrote: Hi I have recently installed the openerp 7.0 community edition, i have below question for the project management module , please help to support. - How can i create Parent and Sub Task , i see there are project stages are those considered as Parent task. - If i enter the start and end date is not suppose to calculate the number of hours for that task, but in my case its not happening there is a column state initial estimated hours , what should i configure so that if i only mentioned the start and end date it should know the number of hours based on calender days. - is there is a way to export the task in excel / csv format please suggest, there is an import option which its showing but no export - is there any extensive document , i have seen couple of help files etc but looking forward for an user manual which can help with real examples, what are the limitation in the community edition is there additional plugin which can help , please suggest. with regards -- Pankaj Dev ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
