Dear framework experts,
like many others real life OpenERP integrators, at Akretion our average
OpenERP is with around 15 extra addons overriding natural behavior to
bring
value added features or localization.
So it's extremely important the normal addons modules can be
overrided in a
decent way.
Otherwise, features are not competitive to create, modules are not
compatible
between them (it's very serious, in Brazil module creating a
purchase/sale/invoice order line or picking should be overriden with a
localization module at this stage, imagine how hard it is for the new
comers,
many non trivial localizations are in the same situation...).
An other consequence is that the overall SQL activity is inefficient, no
matter how perfect the server layer is going to be.
Let's take a concrete example: the sale module and the
action_ship_create
method that generate the shipments and the procurements.
Today it's a massive single bloc of code and customization can only
happen
once the method has been executed (or before but then there is no
reuse and
compatibility at all). That means that we should re-search the
created items,
re-browse them. And depending how we change them later, other modules
doing
that are probably not compatible.
*Instead, I propose to apply 2 general principles:*
*1) any method creating some important
business object (specially something localizable) should give a
chance to a
potential module overrider to customize it BEFORE hitting the
database with
the create method. That creation method should provide all the creation
context (like the order, the product line for a shipment creation) so
the
overrider can take that into account.*
*
*
*2) when there is a what I would call a "cardinalitity mismatch",
that is
stock move lines belong to less (often 1) picking, account move lines
belong
to 1 move... Then there should be a key lookup in a hash to know if the
container object can be reused or need a new instance instead. The
generation
of hat key should be overridable in modules.*
*I proposed a little piece of such work that is waiting for a merge,
please
comment on here:*
https://code.launchpad.net/~akretion-team/openobject-addons/addons-sale-extensible-action-ship-create/+merge/76609
In the future, that behavior could even be abstracted away in some
declarative
and customization fashion. However, let me warn against that. I
suggest to do
that in a declarative style only if perfect, else it's much worse
than python
code. Take the server actions for instance or the methods attached to
workflow
nodes. It's declarative but very little used (python methods are
instead)
because it was far from perfect).
And again, *let me advocate for a working solution right now for
6.1*. Change
can be manage over the time. This has never been done with OpenERP,
but things
can be deprecated 6 months in advance as other framework do. We need a
solution to increase OpenERP adoption. Taking a concrete example,
today in
Brazil, considering that kind of catches less than 5 people are able
to put
OpenERP to work. This is not an ideal solution, neither for us,
neither for
OpenERP SA..
So I kindly request an evalution of this merge. If modules start
using that
modular API instead of hugly mono-bloc overrides, at least in the
future they
will have made a step toward a declarative refactoring, so this is
not a loss,
this is a win. I insist this refactoring is totally backward
compatible and
breaks no API, I was just warning here against the perfect being the
enemy of
the good that too often lead to inaction. The world is not perfect,
third
parties contributions have limited resources and still we should
converge
toward a better solution.
If this merge is accepted, then count on us to provide other such
little life
saver refactorings. This is no surprise that we have a divergence on the
relicense, well I propose to let this aside for now as we need a
decent 6.1
release for the benefit of everybody. You will later be able to claim
that
those merges are under the dual license, at least now the dual
license is known.
Waiting for the merge evaluation.
(BTW we and many Brazilian partners and users are also waiting for a
merge of
l10n_br with correct chart of account more than 4 months now).
