On Fri, Feb 26, 2010 at 5:13 AM, Sebastien LANGE <[email protected]>wrote:
> Hello, > > For one of our customer, we've develop the multi-company with Tiny. But > we've decided to code in next version, actually the trunk because this > version should be freeze in end of december. > > Since January, Tiny developp a lot of new features and now we have a > serious problem with our customer. > > This client has 9 big company and change all their existing software by > OpenERP and now ask me when this version will be freeze. This same customer > purchased a maintenance contract editor where most bugs are not corrected by > the editor and we are therefore obliged to help correct them. > The deadline for our customer is April for using OpenERP in production. > > My question, when this next version will be really freeze ? > Not sure you will appreciate, but from Stephane Wirtel: "two or three months, but there is a milestone on launchpad. " http://www.openobject.com/forum/viewtopic.php?p=52079#52079 For us that's a mixed feeling: it's really delayed compared to the December Tiny told you. Now it gives time to have enough stuff in (had they freezed in December there was almost nothing important other than cosmetic new over 5.2)... We do have the opportunity to jump-start on 5.2 right now. But just like you, wee need a clear visibility. When Tiny says 3 months, well it incentives us to wait for a few more weeks. That's bad cause if we do so, then we don't help as we could, but we aren't kamikaze either. I think this totally demonstrates how pointless the 1 year release policy is: releases are not stable at the date announced cause nobody else than a few Tiny employees worked on it. The first to jump on it, suffer from it rather than being rewarded for their efforts... And it's too long before the next release for integrators to be able to test and contribute features/refactoring. On our side, what would would like in for 5.2: ************* critical: ************* 1) those merges for better extensibility of some modules, Python portability (at least partial for 5.2 and better later; one step at a time): https://code.launchpad.net/~akretion-team/openobject-addons/addons-mxdatetime-free/+merge/20342 https://code.launchpad.net/~akretion-team/openobject-addons/extensible-inventory/+merge/20293 https://code.launchpad.net/~rvalyi/openobject-addons/extensible-mrp/+merge/20294 2) We also have Sebastien Beau working right now on that one: https://blueprints.launchpad.net/openobject-addons/+spec/refactor-old-wizards-on-osv-memory We are trying to refactor the most likely used wizards in osv_memory, that is: - invoice on picking - partial picking - pay invoice and optionally: - group purchase orders - mass reconciliations We will try to come up with a proof of concept tonight and count on the community to help us tackle that short list. 3) We also need at least decent extension points to be able to re-factor the tax_include modules properly. Ideally those would be re-factored in the core. Whether it's possible or not pretty much depends on how important Tiny judge this issue. But Brazilian or US localization really need that in a way that work and plays nice with other modules (so is there a point OpenERP SA open a US office if they are unable to deal with US fiscal rules properly for the whole life of 5.2?) 4) enforce the XML/RPC protocol with error codes: blueprints.launchpad.net/openobject-server/+spec/xmlrpc-should-return-int-faultcodes (would avoid the burden to force each connector to have to parse response strings) ************* Not critical but would be cool to have (would cost little and help a ton, but no need to drag 5.2 for that, specially if release cycle becomes 6 months): ************* 5) search_read method like Tryton (would dramatically speed up clients and also cross languages WS calls) 6) JSON connector (more pure JS possibilities in the browser; faster) 7) WSGI server compliance (for better portability, on J2EE servers for instance, at least as a proof of concept first) 8) YAML data loading (given that OpenERP SA is committed to it already, otherwise not that a priority) ************* Desperate dream list for a better usability (it all depends on how Tiny spots those issues, but I don't want to drag 5.2 specifically for that): ************* 9) one2many management in web client like the GTK client without the need to create resources one by ones 10) Dynamic domain working on selection widget too: https://blueprints.launchpad.net/openobject-server/+spec/dynamic-domain-on-selection-widget 11) symmetric of forms passing parent form params, but for changing them this time: https://blueprints.launchpad.net/openobject-server/+spec/form-parent-field-update-on-change 12) option on many2one widget to allow one-click creation without the need to click through the search popup (combined with 13), could be really more user-friendly) 13) Confirmation dialog pattern: currently, you don't have in OpenERP the option to click to do an action, then the server answers you blabla are you sure? YES | NO So you would have the option to cancel or assume your action. This is a very commonly requested feature and very classical. Customer often want it and it sucks we have to explain them OpenObject doesn't allow that yet. NB: I'm here talking essentially about features that need to change/enrich the core server or addons. Of course lot's of other important features could be contributed. But if they could be contributed as extra modules, then they should not delay 5.2 as they could be added afterwards without breaking any backward compatibility/API. What do you guys think of that list? Have you solutions or are you ready to help on some items? Raphaël Valyi http://www.akretion.com > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
