[IMP] queue: Store context in order to reuse it

[etobella]

With these PR, the context is stored and it can be used in the job.
Sometimes, you don't want to lose the context of the user.

[guewen]

IMO it is better to add an explicit argument in the method if you want to keep something.

[etobella]

That is what I have usually done and I always thought that it was a limitation.
Maybe there is a reason for this behaviour and it is a wrong approach to use this PR.

[pedrobaeza]

I also agree that is good to add corresponding arguments, but there can be context values that are out of your control, like force_company, tz or lang (that doesn't correspond with the job owner lang). Is that the case, @etobella ?

[guewen]

I find that the context is sometimes/often out of control, it may even contain values which cannot be serialized. If the requirement concerns predefined fields, such as force_company, tz, lang, then I would agree that we should keep a stripped-down copy of the context keeping only a list of safe fields.

[etobella]

It is true, that reusing context might be crazy, but it is a tool that is used sometimes and it is interesting to store it somehow. A list of context could be fine. I will work on a safe list of fields.

[etobella]

@guewen The list of safe context keys has been added. It might be better now.

[simahawk]

these methods should be private IMO

[guewen]

Suggestion: setup the context keys to pass on the @job decorator

@job(context_allow=['foo'])

With ['force_company', 'lang', 'tz'] by default and new keys added to the list.
The filtering of the context keys could then be hidden in the job implementation details, instead of cluttering the base model (I try hard to put as less method as possible here).

Would it work for you?

[guewen]

Or if the safe list really needs to be global, then it can be added to queue.job

[etobella]

great idea about the job. I will make the change

[sbidoul]

Will this pass some context to the job by default, that was not passed before?

[etobella]

Yes, the context was not passed to the job.

[sbidoul]

@etobella then I'd say it must not be passed at all unless asked explicitly by the developer, as this could change the behavior of existing deployments.

[etobella]

@sbidoul That is the last change we applied today. The context keys are defined on the job decorator in order to ensure flexibility

[jarroyomorales]

@etobella Travis already fixed in #172

[etobella]

@simahawk your comments have been attended

[lmignon]

With this implementation, how can we add a new key into the allow_contextlist? #273 (comment) could be the right way to provide this kind of info.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[maljac]

Any chance this PR will be merged soon (and maybe ported to v10)?

[guewen]

There is an issue I'm not sure how to handle, which is that in higher versions of Odoo, the context should be stored in the Serialized records (see #281, #283). This change cannot be ported as-is to Odoo 12+. My feeling is that we should address this problem in more recent versions of Odoo, and see how to transition on migrations. Otherwise we will support something in 11.0 that will be lost when you upgrade...

[guewen]

FWIW in many cases (actually I never needed the context for this reason), it is IMO better to pass an explicit argument to the job method than rely on an arbitrary context