[MIG][19.0] partner_multi_company

[Vandan-Pandeji-SerpentCS]

Depending Module: #889

[isturiz]

Hi, check this for dependency: https://github.com/OCA/maintainer-tools/wiki/Use-temporary-reference%28s%29-to-another-pull-request%28s%29

[astirpe]

@Vandan-Pandeji-SerpentCS I opened a PR to your branch: Vandan-Pandeji-SerpentCS#1
Could you have a look?

[EmilioPascual]

Hi @Vandan-Pandeji-SerpentCS! Could you handle the requests and rebase for run runboat? Thank you

@astirpe I don't think he'll reply, it's been two months since you wrote to him. Perhaps, you could add the commit history to your PR and supersed this one if it still doesn't respond . What do you think?

[Vandan-OSI]

Hi @Vandan-Pandeji-SerpentCS! Could you handle the requests and rebase for run runboat? Thank you

@astirpe I don't think he'll reply, it's been two months since you wrote to him. Perhaps, you could add the commit history to your PR and supersed this one if it still doesn't respond . What do you think?

@EmilioPascual I'll take a look at this week & update you.

[Vandan-Pandeji-SerpentCS]

Hi @Vandan-Pandeji-SerpentCS! Could you handle the requests and rebase for run runboat? Thank you

@astirpe I don't think he'll reply, it's been two months since you wrote to him. Perhaps, you could add the commit history to your PR and supersed this one if it still doesn't respond . What do you think?

Done. Please check now.

[EmilioPascual]

Good job @Vandan-Pandeji-SerpentCS

Functional and code review.

[fcvalgar]

Great work, thanks for the contribution @Vandan-Pandeji-SerpentCS . I have reviewed the module and performed the following functional tests in a multi-company environment:

Test 1: OK - Global partner without companies assigned is visible from both companies.
Test 2: OK - Partner restricted to one company is only visible for users with access to that company.
Test 3: OK - Partner assigned to two companies is visible and usable from both companies.
Test 4: OK - When creating a partner, the current company is correctly proposed by default.
Test 5: OK - Removing all companies from a partner makes it available globally again.
Test 6: OK - It is not possible to remove from a user’s partner a company that is still assigned to the related user.
Test 7: OK - Adding a new allowed company to a user correctly updates the related partner companies.
Test 8: OK - Changing the user’s main company keeps the related partner company access consistent.
Test 9: OK - Child contacts correctly follow the commercial partner company configuration.
Test 10: OK - The known roadmap limitation about different companies on child contacts has been reviewed and behaves consistently with the current implementation.
Test 11: OK - After uninstalling the module, the standard partner company rule is restored.
Test 12: OK - Existing partners with a company assigned before installation are correctly migrated to the new multi-company field.

All tested scenarios worked as expected, so this PR looks good to me. Thank you again for the work.

[BhaveshHeliconia]

Code and functional review LGTM!

[mikecolangelo]

Hi @Vandan-Pandeji-SerpentCS, thanks for the migration! While running this port in a real multi-company deployment (Odoo 19, alongside the rest of the multi-company stack) we hit three issues you may want to fold into this PR. Fixes for all three, with regression tests, are on our fork and you're welcome to cherry-pick them:

1. Test suite never actually runs on 19.0 — test_partner_multi_company.py still uses the pre-19 groups_id field in res.users.create(), so setUpClass errors out and every test in the class is skipped. Fix: rename to group_ids. (commit)

2. post_init_hook scopes base.res_partner_rule by the active company selection instead of the user's real membership — the patched rule uses the bare company_ids eval-context variable (self.env.companies, i.e. whatever is checked in the company switcher right now). A company's own contact typically has no linked users, so it doesn't qualify for the partner_share = False branch and falls through to the company check: any user genuinely assigned to a company still gets an AccessError reading that company's own contact the moment their switcher has fewer companies active than they belong to (e.g. an administrator creating a user from Settings). Fix: use user.company_ids.ids in both patched rules. (commit)

3. _check_company_id rejects a transient mid-create state — creating a user whose partner already has a company (an existing partner promoted to user, or any module putting a default on res.partner.company_id, e.g. partner_company_default) with several companies in one create() call crashes with "The partner must have at least all the companies associated with the user": base res.users.create() syncs the partner's company_id mid-create, its inverse narrows company_ids, and the constraint fires before this module's own create override aligns the partner with all the user's companies. Fix: skip the constraint while the user create is in flight; the alignment write re-triggers it on the final state. (commit)

Related: OCA/partner-contact#2401 fixes the partner_company_default side of the same composition problem.

Happy to open a PR against your branch instead if that's easier — just say the word.