openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

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...