Hello,
+1 for Pedro proposition
As the function is decorated with "@tools.ormcache(skiparg=2)" it should
not have a too big negative impact on performance.
We may initialise an empty context if it really causes performance issues.
context_get may also be optimized to use a read instead of a browse.
Regards
Nicolas
2014-08-28 18:45 GMT+02:00 Pedro Manuel Baeza Romero <pedro.ba...@gmail.com>
:
> It looks good to me also, but one detail, put:
>
>
> *if context is None: context = self.pool['res.users'].context_get(cr,
> uid)*
>
> To not make the query when context dictionary is already {} (maybe you can
> be interested in not propagating user context and you pass explicitly
> context={} in your call to the function).
>
> Regards.
>
>
> 2014-08-28 18:35 GMT+02:00 Raphael Valyi <rva...@gmail.com>:
>
> Hello Sandy,
>>
>> I think this is a great idea.
>>
>> It has been debated a few times if it was a bug that the workflow engine
>> doesn't propagate the context. Well in my opinion that's valid to say the
>> context is a compound object made by the user settings, overridden
>> eventually by the parameters of the HTTP request scope. These last
>> parameters stand for user interface details like from which menu you are
>> trying to act on a record or what are the currently selected records. It's
>> normal that the impact of these parameters is limited and it's normal that
>> you can also imagine load the persisted data right from the database
>> instead and still get the right business logic.
>> So in a word, even in the workflow which is supposed to be able to act
>> right on persisted data, it's okay to loose the track of the HTTP request
>> params but as you mentioned this is not a reason to loose the context
>> related to the user settings (language, timezone...)
>>
>> I personally like your proposal for v7. As for v8 the similar logic
>> should happen in the @api decorator providing the context on self and I am
>> not sure, but may be it's already implemented like that.
>>
>> Thanks for the proposition!
>>
>> --
>> Raphaël Valyi
>> Founder and consultant
>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>> +55 21 3942-2434
>> www.akretion.com
>>
>>
>>
>> On Thu, Aug 28, 2014 at 1:04 PM, Sandy Carter <
>> sandy.car...@savoirfairelinux.com> wrote:
>>
>>> Hello community,
>>>
>>>
>>> While debugging yet another translation error in Odoo 7.0, I came up
>>> with a simple way to reclaim lost contexts in functions.
>>>
>>> The bug I was fighting is one where workflow actions do not pass any
>>> contexts. This bug manifests as chattr messages in english when using
>>> the workflows.
>>>
>>> As I don't have the time to fix it in the server, nor am I ready to jump
>>> through the hoops to get that fix integreated in the Odoo, I found a way
>>> to fix this bug in my module.
>>>
>>> The way I countered the bug in my module is in the write function where
>>> I would usually start with
>>>
>>> if context is None:
>>> context = {}
>>>
>>> or
>>>
>>> context = context or {}
>>>
>>> In this case it was None since the workflow mechanism would not have a
>>> context. I saw that since I have the user id, I can still get the
>>> context for this user.
>>>
>>> I replaced the familiar context check with:
>>>
>>> context = context or self.pool['res.users'].context_get(cr, uid)
>>>
>>> I find this simple enough. The line is under 80 characters and it can
>>> replace the usual context check.
>>>
>>> Furthermore it assures that everything done within this function and its
>>> parent functions have at least the language in the context, something I
>>> have been struggling with a lot lately.
>>>
>>>
>>> What does the community think of this as a possible standard for
>>> modules, replacing the usual if context is None lines.
>>>
>>> Are there possible drawbacks to using this line?
>>>
>>> Thank you for you input!
>>>
>>> --
>>> Sandy Carter
>>> Consultant en logiciel libre
>>> Développeur OpenERP
>>> Savoir-faire Linux Inc.
>>> 514-276-5468 poste 142
>>> http://www.savoirfairelinux.com
>>> sandy.car...@savoirfairelinux.com
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openerp-community
>>> Post to : openerp-community@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openerp-community
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to : openerp-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to : openerp-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openerp-community
> More help : https://help.launchpad.net/ListHelp
>
>
--
Nicolas Bessi
Senior ERP consultant
Business Solution technical manager
Camptocamp SA
PSE A
CH-1015 Lausanne
http://openerp.camptocamp.com
Direct: +41 21 619 10 26
Office: +41 21 619 10 10
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
