magento-openerp-synchro module: we moved to Launchpad!
Raphaël Valyi
But we are now seeing too much interest in that connector poping all
over the world to continue the development in a centralized way. Also,
we have been contacted by Jordi Esteve, the primary extern OpenERP
contributor (after Launchpad stats) who wanted to jump in and join
efforts, so he also asked us to move the contribution process forward.
That's why we have the pleasure to announce you that we migrated our
development trunk from Google Code SVN to Bazaar on Launchpad, meaning
we just use the advised OpenERP community advised distributed
development platform. Also notice that we took care of migrating the
previous SVN commits.
That was also the occasion to split the development in two branches:
* a 4.2 compatible maintenance Branch. That one is for the
conservative folks who can't afford migrating to OpenERP v5
https://code.launchpad.net/~openerp-commiter/openobject-addons/4.2-extra-addons
* a 5.x branch where all the new interesting stuff is expected to
happen: https://code.launchpad.net/~openerp-commiter/openobject-addons/trunk-extra-addons
In both cases, the OpenERP addon module name is now called
magento_openerp_synchro.
The last SVN version (revision #27) has been ported as bzr revision
#3581.1.9 on v5 branch and rev #148 in 4.2 branch. Later on both
branches got a fix for issue
http://code.google.com/p/magento-openerp-smile-synchro/issues/detail?id=31
v5 branch got even more attention and code clean up.
So you are very much welcome to jump in and contribute to whatever
branch you need. Still, before adding any serious extra feature, we
would like to insist that some refactoring should be undertaken BEFORE
bloating the code.
Especially:
1. Too much code is lying inside the OpenERP wizard layers. That
was a bad design choice making it hard for additionnal third party
modules to extend the connector behavior and add custom features that
way OpenERP allows it (thanks to its extensive OOP design). Instead,
that code should be moved INSIDE THE OBJECT LAYER. That shouldn't be
to hard, it's only about extracting methods, putting them in the
appropriated objects (sale order, product...) and calling those
methods from the wizards instead. For instance we deployed a derived
version of that connector for a customer along with the
sale_supplier_direct_delivery module and we had to hardcode the
connector to make it account for the direct delivery eventuallity.
With the new design things should work more seamlessly. See the
following tracker:
http://code.google.com/p/magento-openerp-smile-synchro/issues/detail?id=32
2. The sale order push feature (from Magento) has not beeing
integrated properly yet and is still polluting the code. It has been a
wonderfull contribution by Charles Galpin, but we had not time to
integrate it the way we wanted to and it has not been tested
extensively. Instead, we would like to remove the push code from
Magento and instead makes Magento call OpenERP and tell him to pull
the given sale order reusing it's standar sale order import code.
Finally that design should be able to deal with possible network or
OpenERP failure and flag failing push inside Magento for later
processing. Not at top priority, but something you should be aware of.
See following tracker:
http://code.google.com/p/magento-openerp-smile-synchro/issues/detail?id=33
3. Finally, we insist that we din't take care yet of exposing ALL
OpenERP XML/RPC server webservice the standard Magento way. One of the
consequences is that currently importing sale orders is not secure
unless you block external connections by IP at say an Apache level. A
much better way would be to properly expose our custom extra
webservice the Magento way, see the following tracker:
http://code.google.com/p/magento-openerp-smile-synchro/issues/detail?id=6
Meanwhile we welcome Jordi Esteve as a core contributor + project
member. We know that things have been a bit slow with Smile and the
connector recently (we are flooded by OpenERP non Magento demand), but
we really hope to help moving foward as much as we can. We really hope
all those inputs will streamline the installation process + natively
supported features while minimizing the required development skills.
Enjoy!
Raphaël Valyi