openerp-community team mailing list archive

[sebastien beau <sebastien.beau@xxxxxxxxxxxx>]

Hi Eric
For salling between company we have some prototype on it, I will push it
next week and send you an email (and also to community).

Hi Niels

Yes handled automatically the view is cool, and I tryed to did the same
thing for the method, but it's not so easy :(

Indeed when the method have for args something like "cr, uid, ids" it's
easy but sometime method can have specific arguments.
In this case it's really hard et in some case impossible to test
automatically the method.
This is why I think we have to use a volunteering process in order to keep
the posibility to use method with specific arguments and so specific
testing, what do you think?

Regarding the solution with a decorator. In my first POC (not the version
push) I try to used a python decorator for all generic method (method
starting by "cr, uid, ids")
The idea was to use the decorator : @only_for_module('module_name')

and using it like that :

@only_for_module('module_name')
def ma_method_overwrited(self, cr, uid, ids, ....):


instead of :

def ma_method_overwrited(self, cr, uid, ids, ....):
    if self._check_module_allowed(...)
        ....
    else:
        return super(...)

I finally chose the solution with self._check_module_allowed(..) in order
to force the developper to take care about the args of the method, but we
can change and use a decorator instead.


Here my first prototype with a decorator, it's work but maybe it's not so
clean

===========================================================================================
from osv import osv
import functools

def only_for_module(module):
    """
    This decorator will check if the func of the current module should be
apply for the current company
    """
    def decorator(func):
        @functools.wraps(func)
        def wrapped(self, cr, uid, ids, *args, **kwargs):
            context = kwargs.get('context')
            if 'company_id' in self._columns:
                current_object = self.browse(cr, uid, ids[0],
context=context)
                exclude =
current_object.company_id.check_exclude_module(module, context=context)
            else:
                user = self.pool.get('res.users').browse(cr, uid, uid,
context=context)
                exclude = user.company_id.check_exclude_module(module,
context=context)

            if not exclude:
                return func(self, cr, uid, ids, *args, **kwargs)
            else:
                name = func.__name__
                use_next_class = False
                for base in self.__class__.mro()[1:]:
                    if use_next_class and hasattr(base, name):
                        return getattr(base, name)(self, cr, uid, ids,
*args, **kwargs)
                    class_func = base.__dict__.get(name)
                    if class_func:
                        original_func =
class_func.__dict__.get("_check_company_original_func_before_wrap")
                        if original_func is func:
                            use_next_class = True
                raise osv.except_osv(_("Not Implemented"), _("Not parent
method found"))
        wrapped._check_company_original_func_before_wrap = func
        return wrapped
    return decorator
======================================================================================


Thanks for your feedback




2012/12/11 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
>
>
> _______________________________________________
> 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
>
>


-- 

BEAU Sébastien
MagentoERPconnect Project Manager at Akretion
twitter : seb_beau
skype : sebastien_beau
www.akretion.com
http://launchpad.net/magentoerpconnect