openerp-community team mailing list archive

[Niels Huylebroeck <nh@xxxxxxxxxx>]

I like how you handled the view, for the method however I think a
volunteering process is not the best solution.

We might have to do some more introspection to actively deny executing
overridden methods from localization modules (similar to how we intercept
the view). One way to do this in python is overriding the __getattr__
method override (See [1]) on the osv.orm.Model object. The downside on this
is possibly that it has a wide impact which would mean some (although
minor) global performance loss.

Should this not be possible the current process would have to be simplified
by using decorators for example instead of using
self._check_module_allowed(...) calls.

Regards,
Niels

[1]
http://docs.python.org/2/reference/datamodel.html#object.__getattribute__


2012/12/11 Eric Caudal <eric.caudal@xxxxxxxxxxxxxx>

>  That sounds promising: we will test it!
> On our side we are working on refactoring completely the intercompany
> process (SO<=>PO, CI<=>SI, DN<=>IS) with 2 new projects (multi-company
> process is very common in China) and might come soon with a blueprint on
> this topic.
>
>  Eric Caudal*CEO*
> --*Elico Corporation, Shanghai branchOpenERP Premium Certified Training Partner *
> Cell: + 86 186 2136 1670
> Office: + 86 21 6211 8017/27/37
> Skype: elico.corperic.caudal@elico-corp.comhttp://www.elico-corp.com
>
> [image: Elico Corp]
> On 12/11/2012 12:59 AM, sebastien beau wrote:
>
> Dear Community,
>
>  As you know when you use OpenERP with multiple localizations you will
> face some problems. Indeed each localization can change the views, the menu
> and also overwrite the initial python method. For now there is no standard
> for making localization compatible. So I propose to create an abstract
> module that will provide us tools for solving the problem.
>
>  My idea is simple: instead of doing a lot of ugly code in the xml for
> trying to hide some field depending in the localization (and the same for
> the menu) it will be easier to hide automatically every view for a module
> (and the same for the menu).
> For the python part I propose to use an abstraction for testing if we have
> or not to execute the code.
>
>  A prototype can be found here :
> https://code.launchpad.net/~extra-addons-commiter/+junk/POC-multi-localization<https://code.launchpad.net/%7Eextra-addons-commiter/+junk/POC-multi-localization>
> Try it, fork it, improve it
>
>  The module multicompany_module_selector add the possibility to unactive
> a module for a company (open the menu company and add the module to
> unactive)
>
>  The module fake_company_1 and fake_company_2 are fake module for testing
> the POC
>
>  What does the multicompany_module_selector:
> - it overwrites the build of the view and exclude all of the view added by
> the module unactivated for a specific company
> - it overwrite the build of the menu and exclude all of the menu added by
> the module unactivated nactivated for a specific company
> - it add the “_check_module_allowed” method on the class Model in order to
> test easily the localisation.
>
>  You can try it, for that just install the 3 modules.
> Then create 3 companies and 3 users (on user per company)
> For the company 1, unactive the module ‘fake_localization_2’
>  For the company 2, unactive the module ‘fake_localization_1’
>
>  Now with the user 3, open a sale order you will see the field added by
> the localization 1 and 2
> Create a sale order and validate it, you will see that the sale_order pass
> in the python code of the localisation 1 and 2
>
>  Now with the user 1, open a sale order you will see the field added by
> the localization 1/ Create a sale order and validate it, you will see that
> the sale_order pass in the python code of the localisation 1
>
>  Now with the user 2, open a sale order you will see the field added by
> the localization 2
> Create a sale order and validate it, you will see that the sale_order pass
> in the python code of the localisation 2
>
>
>  This is a POC; it needs more work to have something good. But before
> working more on it, I would like to have your opinion. Indeed we really
> need to find a good solution for making localization compatible without
> headache
>
>  Thanks for helping us
>
>  --
>
> BEAU Sébastien
> MagentoERPconnect Project Manager at Akretion
> twitter : seb_beau
> skype : sebastien_beau
> www.akretion.com
> http://launchpad.net/magentoerpconnect
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Niels Huylebroeck
Lead Architect   --   Agaplan
Tel. : +32 (0) 93 95 98 90
Web : http://www.agaplan.eu