Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FIX] base: synchronize (non-false) company_id to child contacts #31364

Closed
wants to merge 1 commit into from

Conversation

len-foss
Copy link
Contributor

Let the database be in multi-company with unshared contact catalog.
Let F be a filter "('partner_id', 'not ilike', 'string')" on invoices.
If there is a contact which parent belongs to another company,
then this parent cannot be read.
Thus the name_get on partner can create an access error.
As a result applying the filter F would fail and return no results.

It generally doesn't make much sense to have a contact company X, which belongs
to the Odoo Company OC1, while its child contacts are in another Odoo company,
since many fields are directly computed from the parent.
However it is useful to have X belongs to no company, while it has child
contacts X>Yi belonging to company OCi.
In the first case it can create access errors interrupting the normal flow of
operations, while the latter should not.

To forbid the first case while allowing the second, we synchronize company_id,
but add a special case to ignore it if it set to False.

Note that PR#30997 should be used in case the name_get causes an error for
another reason that is deemed a legitimate use-case.

opw 1933862

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Let the database be in multi-company with unshared contact catalog.
Let F be a filter "('partner_id', 'not ilike', 'string')" on invoices.
If there is a contact which parent belongs to another company,
then this parent cannot be read.
Thus the name_get on partner can create an access error.
As a result applying the filter F would fail and return no results.

It generally doesn't make much sense to have a contact company X, which belongs
to the Odoo Company OC1, while its child contacts are in another Odoo company,
since many fields are directly computed from the parent.
However it is useful to have X belongs to no company, while it has child
contacts X>Yi belonging to company OCi.
In the first case it can create access errors interrupting the normal flow of
operations, while the latter should not.

To forbid the first case while allowing the second, we synchronize company_id,
but add a special case to ignore it if it set to False.

Note that PR#30997 should be used in case the name_get causes an error for
another reason that is deemed a legitimate use-case.

opw 1933862
@C3POdoo C3POdoo added the OE the report is linked to a support ticket (opw-...) label Feb 22, 2019
@robodoo robodoo added the CI 🤖 Robodoo has seen passing statuses label Feb 22, 2019
@len-foss
Copy link
Contributor Author

robodoo r+

robodoo pushed a commit that referenced this pull request Feb 22, 2019
Let the database be in multi-company with unshared contact catalog.
Let F be a filter "('partner_id', 'not ilike', 'string')" on invoices.
If there is a contact which parent belongs to another company,
then this parent cannot be read.
Thus the name_get on partner can create an access error.
As a result applying the filter F would fail and return no results.

It generally doesn't make much sense to have a contact company X, which belongs
to the Odoo Company OC1, while its child contacts are in another Odoo company,
since many fields are directly computed from the parent.
However it is useful to have X belongs to no company, while it has child
contacts X>Yi belonging to company OCi.
In the first case it can create access errors interrupting the normal flow of
operations, while the latter should not.

To forbid the first case while allowing the second, we synchronize company_id,
but add a special case to ignore it if it set to False.

Note that PR#30997 should be used in case the name_get causes an error for
another reason that is deemed a legitimate use-case.

opw 1933862

closes #31364
@robodoo
Copy link
Contributor

robodoo commented Feb 22, 2019

Merged, thanks!

@robodoo robodoo closed this Feb 22, 2019
@len-foss len-foss deleted the master-opw1933862-ctctx-len branch February 26, 2019 07:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI 🤖 Robodoo has seen passing statuses OE the report is linked to a support ticket (opw-...)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants