On 10/04/2012 09:13 AM, Alan Lord wrote: > On twitter[1] Olivier indicated that some of the features of *_layout > will be incorporated as standard into 7. > > A couple of days ago I updated our trunk system and even the ability to > re-order line items seems to have disappeared.
The fact that the reordering does not work anymore is a bug in trunk (keep in mind that trunk is not a stable branch), and will be fixed soon. > For our customer(s), it actually gets a bit worse as they really want to > have the *_layout functionality work across the entire workflow so that > the information which is carefully built into the original Quotation, > Notes, order of items, sub-totals, headings etc. gets transferred to the > Delivery Order and ultimately to an Invoice too. Ordering should indeed propagate throughout the whole workflow, this bug will be fixed soon too. > As this is a critical piece of functionality I would like to know if > there is a plan within OpenERP for the _layout replacement, and if so > what specific features will be available in 7 and what will be removed? > We need this fairly soon so we can start to plan with our customer and > determine what features we will need to write ourselves... The plan is: - line ordering enabled by default without needing an extra module - line ordering propagates throughout the workflow by default - multi-line/complex description allowed for each line by default, reducing the need for notes/titles/etc - nothing planned to replace subtotals/title/etc. For the record, we had to drop the *_layout modules because having dummy lines mixed within normal lines is not a clean data model, and proved to be very error-prone. Every single part of the system that deals with the lines (to count, print, display, get stats, etc.) needs to be adapted when the *_layout stuff is enabled, and that is not feasible. It is not the first time similar designs had to be abandoned, and we'll stay away from this in the future. Modularity is good, but modules should never directly alter the core semantics of the things they build upon. A sale order line is meant to be an item that is being sold, and every part of the workflow that deals with these items will behave as expected. If someone can come up with a clever module that does the extra things that your customers need (better structure for large orders with titles or whatever), but without adding the dummy lines, then we'll certainly consider it for inclusion in the official distribution. However we're unlikely to have any internal resources to dedicate to it (for 7.0 at least). We know there is some feature loss in this transition, but we want to apply a consistent strategy on OpenERP features from now on: "make it right or drop it". Fewer, better features, rather than more half-broken ones. If a feature can be made solid and easily maintainable (a sign of good design), then we fix it and keep it. If a feature cannot be fixed cleanly we prefer to drop it rather than keep something that will cause bad surprises for both users and maintainers all the time. We might add it back later when we find a way to fix the flaw. Oh and this only means that the *_layout modules will not be maintained/supported by OpenERP S.A. in 7.0. Users with an OpenERP Enterprise contract who are migrating from 6.1 should be sure to discuss this topic with our migration team if they rely on this feature: a proper solution will be found. And of course you're still free to port them from 6.1 and use them if you like (it won't preclude future migrations, etc.) > PS: This whole thing has made me wonder... Why is the whole line-item > code different between the various objects anyway? Would it not make > more sense to have a single chunk of code (a line_item module) that > deals with line sequencing, notes and other features etc. and make it > the *same* across the whole system? That is a complicated software design trade-off. There are often two ways to design a feature: make it very generic and risk ending up with an inflexible monster once everything is factored in, or make it specific for the job, and risk having some level of duplication. In this case the various types of line-items are different enough that extracting the commonalities between them will actually add overhead to the system, while making the design more complicated. I hope this clarifies a bit the situation... _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
