[19.0][ADD] partner_multi_company_restrict - #1024
Draft
mikecolangelo wants to merge 8 commits into
Draft
Conversation
… to own company base.res_partner_rule always exempts any contact linked to an internal user (partner_share=False) from company scoping, so a colleague's contact from another company stays visible to a merchant without multi-company access. This adds a second, global ir.rule (ANDed with the existing one) that requires the contact to also belong to the viewer's own company, unless they hold base.group_multi_company, it is their own contact, or it has been deliberately shared (blank company_ids). Depends on partner_multi_company, not yet in this branch's tree (queued behind that migration's own PR).
OCA-git-bot
added
series:19.0
mod:partner_multi_company_restrict
Every user, however many companies they are allowed into, only sees a colleague's contact if it belongs to a company they are actually assigned to. A real system administrator does not need a bypass: paired with res_company_admin_sync (a separate, internal module keeping them assigned to every company), the plain company-scoping condition already lets them see everything.
A company's own contact was created with a blank company_ids (the 'shared' convention), keeping it visible to everyone regardless of company since it isn't an internal-user contact and thus falls outside this module's rule entirely. Fix the data instead of adding another rule: a res.company override scopes new companies to themselves, and a post_init_hook backfills existing ones.
…sn't readable mail.thread's message_partner_ids computes via a raw browse() of every follower's partner id, regardless of whether the current user can read each one. Field conversion later checks each one's active field to build the recordset, which enforces record rules -- so reading a document crashes the instant a follower is hidden by any partner-visibility restriction, such as this repo's partner_multi_company_restrict. Fix: recompute the visible follower list through search() instead of browse(), which applies record rules up front and silently omits what the user can't see. General-purpose fix, does not depend on partner_multi_company_restrict.
…s_fix __init__.py never imported hooks.post_init_hook, so Odoo's loader raised AttributeError on a fresh install (only exercised by 'install', not by '-u' on an already-installed module, which is how this went unnoticed). Also declare mail_thread_followers_access_fix as a hard dependency so it is impossible to install this module without the fix that keeps chatter/followers from crashing when a colleague's contact is hidden.
OCA-git-bot
added
the
mod:mail_thread_followers_access_fix
…ection
Creating a new internal user as an administrator crashed with an
AccessError whenever the company switcher had only some of the
administrator's companies active, not all of them. Odoo's own error
hint ("switch to company: X") pointed at the real cause.
Root cause: the company-scoping branch used the ir.rule eval-context's
bare company_ids variable, which is self.env.companies (only the
companies currently checked in the switcher), not
self.env.user.company_ids (every company the user actually belongs
to). Core Odoo has multiple built-in mechanisms that read another
internal user's contact regardless of the acting user's active company
selection -- this one came from Discuss auto-subscribing every
internal user to a channel when a new user is created, which
enumerates every user in the relevant group, not just the ones sharing
the active company.
Fix: scope by user.company_ids instead. Visibility should depend on
company membership, not on an ephemeral UI toggle. Verified this does
not reopen the isolation gap: a user still cannot see a company they
are not a member of, regardless of context. New regression test
reproduces the exact scenario (member of 2 companies, only 1 active).
…company A user genuinely assigned to several companies sees colleagues from all of them in Contacts regardless of which one is checked in the company switcher right now, by design: the ir.rule scopes by real membership, not the active selection, on purpose. That's correct for security, but confusing for display. Add a "My Active Company" search filter to Contacts, on by default, narrowing the list to the active company selection. Purely a view-level default, not a security change: removable with one click, and never widens what a user could already access.
… active company" This reverts commit c1851ae.
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.
Problem
base.res_partner_rule(as patched bypartner_multi_company'spost_init_hook)always exempts any contact linked to an internal user (
partner_share = False)from the company scoping, so that "assigned to" pickers and similar widgets keep
working. On a multi-company deployment this means a user without multi-company
access can still see (and interact with) a colleague's contact from a
different company they have no relationship with.
Solution
Adds a second, global
ir.ruleonres.partner. Global rules combine with alogical AND (see
ir.rule._compute_domain), so this tightens the exemptionwithout touching the existing rule: a user without
base.group_multi_companyonly sees a colleague's contact if it belongs to their own company, is their
own contact, or has been deliberately shared (blank
company_ids).Configurable from Settings > General Settings > Companies, enabled by
default.
Status
Draft: depends on
partner_multi_company, which is not yet merged intothis branch (see #901). Marking ready for review once that lands.
Companion module
partner_hide_admin_contact(hiding administrators'contacts specifically, unrelated to multi-company) will be proposed
separately against
OCA/partner-contact.