[13.0][IMP] queue_job current company

[acsonefho]

I currently have some trouble to trigger job because they use the default company of the user instead of the active one.
I see this open discussion: #363 but IMO using a serialized context is not in opposition with this solution as the key allowed_company_ids is not always in the context (only if the user switch company?).

I did 2 commits (IMO it's important to keep them):

1. Force companies into the context (via allowed_company_ids key)
2. Only load the job's company into allowed_company_ids because it could load too many unexpected records (during search).

[OCA-git-bot]

Hi @acsonefho! The addon you are improving has no declared maintainer.
If you care, you can consider adopting it. To do so, please read the
maintainer role description then create a
pull request to add your GitHub login to the maintainers key of the
addon manifest.

[sbidoul]

Shouldn't we rather design the jobs to work correctly irrespective of the user and job company_id ?

[guewen]

Hi, maybe I don't get the use case properly, but I'm not sure to agree with:

using a serialized context is not in opposition with this solution as the key allowed_company_ids is not always in the context

If the job was called synchronously like a normal method, and the allowed_company_ids was not in the context, you would have the same issue then? So it means the issue is on the caller not setting it. I don't see why calling asynchronously would need to have a different behavior? And if the caller did set allowed_company_ids then if we store the context, we'll have it automatically.

[acsonefho]

Hi, maybe I don't get the use case properly, but I'm not sure to agree with:

using a serialized context is not in opposition with this solution as the key allowed_company_ids is not always in the context

If the job was called synchronously like a normal method, and the allowed_company_ids was not in the context, you would have the same issue then? So it means the issue is on the caller not setting it. I don't see why calling asynchronously would need to have a different behavior? And if the caller did set allowed_company_ids then if we store the context, we'll have it automatically.

IMO if the allowed_company_ids is not into the context, so the default company of the user is used. So job.company_id == self.env.user.company_id == self.env.company is True so no issue.
But if the user switch company to trigger a job, job.company_id == self.env.user.company_id == self.env.company become False. But job.company_id == self.env.company still True. It's why it's required to keep the current company to trigger the job.

I totally agree with the option to store the context into the job. That fix this company issue. But for now as nobody agree to store it

[guewen]

But for now as nobody agree to store it

I do agree to store it (in the recordset as discussed in #281 (comment)), I proposed it here #283. I'm sure other people agree too, the variances of opinions may be more in what exactly in the context we allow to store or not, but we can start small with an allow-list with the standard keys.
It's just that nobody worked on it.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.