[19.0][ADD] multi_company_field_visible (+ partner/product bridges)#1018
Draft
mikecolangelo wants to merge 6 commits into
Draft
[19.0][ADD] multi_company_field_visible (+ partner/product bridges)#1018mikecolangelo wants to merge 6 commits into
mikecolangelo wants to merge 6 commits into
Conversation
OCA-git-bot
added
series:19.0
mod:product_multi_company_field_visible
Expose an Own Company proxy field on models based on multi.company.abstract so users without the multi-company group can see and manage only their own company, never other companies of a shared/global record. Editable with a safe merge that preserves hidden companies, never left blank, and fails closed against escalation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auto-installed bridge exposing the Own Company field on the contact form when partner_multi_company is present, with a per-model toggle in Settings. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auto-installed bridge exposing the Own Company field on the product form when product_multi_company is present, with a per-model toggle in Settings. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mikecolangelo
force-pushed
the
19.0-add-multi_company_field_visible
branch
from
3bb586e to
4e0bd16
Compare
mikecolangelo
added a commit
to CanariasConectada/multi-company
that referenced
this pull request
Jul 1, 2026
…(README.rst, pyproject.toml, static/description) Bring in the pre-commit-generated boilerplate from the sibling incubation branch 19.0-add-multi_company_field_visible (base of upstream OCA PR OCA#1018), which had it but this branch's copy (taken from /tmp) did not.
…write, not via constrains @api.constrains reads company_ids while it is still protected mid-write (it feeds the computed company_id), seeing the pre-write value -- so a non-admin could clear it via a direct write() bypassing the safe own_company_ids proxy and it silently passed. Move the check to run after write()/create() return, once the field is consistent again.
…any selection own_company_ids' compute intersects the record's companies with self.env.user.company_ids (every company the user belongs to), not self.env.companies (only the ones currently active in the company switcher). Assigning a Many2many field -- even just to fill a compute's cache -- goes through the same write path as a real edit, checking 'read' access on any newly-referenced res.company; that rule scopes by the ACTIVE selection, so a company the user owns but didn't select fails the check and crashes the whole read. Fix: skip the proxy field's compute entirely when it isn't needed (multi-company users never see it -- show_own_company_field is already False for them). New regression test reproduces the scenario (2 companies, 1 active) and confirms it no longer crashes.
…ny is created res.company.create() creates the company's own contact through a nested res.partner.create() call, marked with the context key default_parent_id=False. As part of that nested create, base_multi_company's company_id inverse fires and briefly writes a blank company_ids on that very partner (it has nothing to compute company_id from yet: the company doesn't point partner_id back to it until a moment later). _check_own_company_not_blank rejected that transient, purely internal state as if it were a real user edit, so creating any company crashed the instant this module was installed. Found via an exhaustive cross-module health check installing and testing the whole multi-company stack together from scratch, something no single module's own test suite exercises on its own. Skip the check specifically for that context marker; a genuine attempt to blank out company_ids by a real user is still rejected (verified with a regression test and manually against a non-admin user).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a small module stack that lets users without the multi-company group see and
manage the company membership of their own records, without ever exposing the other
companies a shared/global record may belong to.
multi_company_field_visible(base): adds anOwn Companyproxy field on every modelbased on
multi.company.abstract.partner_multi_company_field_visible/product_multi_company_field_visible:auto_installbridges that expose the field on the contact / product form, each with aper-model toggle in Settings > Companies.
Why
partner_multi_company/product_multi_companyaddcompany_idsbut gate it behindgroups="base.group_multi_company", so a single-company merchant can't see or set thecompany of their own records. Removing the group would leak information:
company_idscancontain other companies (shared/global records). No OCA module currently filters which
companies are shown, so this builds it.
How
company_ids ∩ self.env.user.company_ids— the realcompany_idsnever reaches the client, so other companies can't be enumerated.user's own companies are accepted, and the field is never left blank (falls back to
env.company). It fails closed against escalation.company_idsfield untouched (includingthe empty = "all companies" / global semantics).
Security-first: record rules are not touched — the real isolation is still enforced by the
existing OCA rules. Only the UI and a safe inverse change.
Note on dependencies
This stack depends on
partner_multi_company/product_multi_company, whose 19.0 portsare still in flight (e.g. #1014). Opening as draft until those land on 19.0. Feedback on
naming and approach is very welcome in the meantime.
@OCA/multi-company-maintainers