Sharing coverage gap: territory/team-shared accounts show quote, task and contract related lists the rep cannot read

[yinlianghui]

Split out of #488. The object-grant half was fixed in #547; this is the remaining record-level coverage question, kept separate because it needs a business decision, not just metadata.

The gap

sales_rep holds readScope: 'own' on crm_quote, crm_task and crm_contract (all private OWD), and no sharing rule exists for any of these objects. Meanwhile accounts do have widening rules (north_america_territory, europe_territory, account_team_sharing).

So a rep who receives an account through a territory rule opens it and finds:

• the Contacts related list populated (contacts are controlled_by_parent → follow the account),
• the Opportunities / Quotes / Contracts / Tasks related lists empty or partial — those objects stay own-only, and nothing derives or shares them alongside the account.

The page promises a 360° view of the shared account; record-level security delivers a keyhole. Same shape for service_agent: they read the account org-wide but see only their own cases/tasks on it.

Decision needed (per object)

Whose records should someone see on an account they can read but don't own?

Object	Option 1 — criteria sharing rule	Option 2 — OWD change	Option 3 — status quo
crm_quote	Share quotes whose account matches the territory rules (duplicates the territory criteria per child object; brittle)	controlled_by_parent on the opportunity or account — pricing follows the deal	Own-only is arguably correct for pricing
crm_contract	Share active contracts with the account's team	controlled_by_parent (account) — a contract is account data	Own-only hides renewals from the very team sharing the account
crm_task	Share open tasks by account territory	Keep private — tasks are personal by design	Probably fine as-is

Notes:

• Option 2 for quotes/contracts is the structurally honest fix (same reasoning that moved the line items in fix(security): grant the six objects that had no permissions at all (#488) #547), but it widens visibility for everyone, not just territory recipients — that's the business call.
• Option 1 keeps private but every account-sharing rule then needs a mirrored rule per child object, and the criteria drift apart over time.
• Whatever is chosen, crm_opportunity has the same question one level up (own-only + a single ≥$100k director rule), and Ownership model mismatch: app-authored owner lookups vs the platform's owner_id — reassigning Owner in the UI does not move record access #548 (owner vs owner_id) affects how "own" is evaluated everywhere here.

test/authorization-coverage.test.ts (added in #547) will keep whatever is decided consistent — e.g. if quotes go controlled_by_parent, the inert-scope and parent-resolution checks apply automatically.

[yinlianghui]

Re-verified against main (0437c9f) — the gap is still there

• crm_quote, crm_contract, crm_task: sharingModel: 'private', and objectstack.config.ts registers 9 sharing rules — 3 on crm_account, 2 on crm_opportunity, 2 on crm_case, 2 on crm_campaign. None on quote/contract/task.
• sales_rep holds readScope: 'own' on all three; service_agent holds it on crm_task and crm_case.
• So the account's related lists split exactly as reported: Contacts follow (controlled_by_parent), everything else is own-only except the ≥ $100k / critical-case leadership rules.

Two things worth adding before the decision, because they change what the options cost.

Option 1 is not authorable today without a schema change

The rule the issue sketches ("share quotes whose account matches the territory rules") has nothing to match on. The territory predicate is record.billing_address.country in [...] — billing_address is a structured address field on the account itself, not a traversal. A criteria rule on crm_quote is evaluated against the quote's own columns, and a quote carries no country, region or territory field. Whether the predicate compiler will dot-walk a lookup (record.crm_account.billing_address.country) is unproven in this app — nothing ships that shape, so it would need a platform check before anyone plans around it.

Assume it does not, and Option 1 costs: a denormalized territory/billing_country field on each child object, a hook keeping it in sync when the account moves territory or the child is reparented, and N mirrored rules that drift from the account rules over time. That is materially more expensive than the issue's "duplicates the criteria per child object; brittle" suggests.

Option 2 is available for quote and contract, and structurally impossible for task

Object	Parent for derivation	Option 2 viable?
crm_quote	crm_account — required: true, notNull	Yes
crm_contract	crm_account — required: true, notNull	Yes
crm_task	related_to_account / _contact / _opportunity / _lead / _case, all optional, selected by related_to_type	No — ADR-0055 derivation needs one master-detail or one required lookup. With none, the guard in test/authorization-coverage.test.ts fails and the layer denies every row. Making a parent required would break standalone tasks (a task tied to no record).

So the task row of the table really only has Option 1 (with the denormalization cost above) or Option 3.

What Option 2 actually widens

Read is the small half. On a controlled_by_parent object, write requires edit on the parent — and the territory rules grant edit on accounts, as does account_team_sharing for sales_manager.

• crm_contract — narrow blast radius. sales_rep holds allowCreate: false, allowEdit: false on contracts, so the object gate stops writes regardless of the derived row access. Effectively this is a read widening: anyone who can read the account reads its contracts. That matches the issue's "a contract is account data" reading, and it is the cheapest of the three to reason about.
• crm_quote — wider than it looks. sales_rep holds full CRUD on quotes, so every na_sales_team / eu_sales_team member would gain edit on quotes in their territory, not just read: pricing, discounts and internal_notes (readable+editable for reps under FLS today). crm_quote_line_item is itself controlled_by_parent(crm_quote), so this also creates a two-level derivation chain — also unverified in this app, and worth a platform check before committing.

Mechanical follow-ons either way: the readScope: 'own' on any object that goes controlled_by_parent must be deleted (the inert-scope guard from #547 fails otherwise), the OWD table and the new related-list table in content/docs/administration/sharing-and-security.mdx need updating, and the ledger in test/sharing-coverage.test.ts needs the new classification. And as the issue notes, #548 changes how "own" is evaluated underneath all of this.

Cost summary

	Option 1 — criteria rule	Option 2 — controlled_by_parent	Option 3 — status quo
crm_quote	Needs a denormalized territory field + sync hook + a mirrored rule per account rule	Read and edit widen to every territory/team member; two-level line-item derivation unverified	Pricing stays with the owner; the Quotes related list stays empty for territory recipients
crm_contract	Same denormalization cost	Read widens to anyone who reads the account; writes still blocked by the object gate for reps	Renewals stay hidden from the team that holds the account
crm_task	Same denormalization cost	Not available — no resolvable parent	Personal-by-design; probably fine, per the issue

Not deciding this — one observation

If the goal is the 360° view the account page implies, crm_contract gets closest for the least widening, crm_quote is the one that deserves an explicit "should territory peers edit each other's pricing?" answer before anything moves, and crm_task has no cheap path at all. That is a business call, not a metadata one, so it stays here.

What #584 does in the meantime

#584 fixes only the half that is unambiguously a defect — the docs described access the app does not ship:

• content/docs/revenue/contracts.mdx claimed "Contracts follow the account's sharing — if you can see the account, you can see its contracts". It does not, and never did.
• The security doc documented an account-team roster and a Team tab that this app has no object for; account_team_sharing is an ordinary criteria rule granting sales_manager edit on active customer accounts. The FAQ sent users to ask for a seat on that non-existent team.
• Profile comments claimed reps get cross-team visibility "through the account team / territory sharing rules" — true for accounts and contacts, false for quotes, contracts and tasks.

No OWD, permission set or sharing rule changed. New guards in test/sharing-coverage.test.ts pin the shipped reach per account child and hold the docs to it, so whichever option is chosen has to update the ledger and the prose together.

Two unrelated defects surfaced while reading the docs and are left for their own issues: the Competitor object documented in the OWD table and in profiles.mdx does not exist (competitors are a picklist on crm_opportunity), and ~38 lines across ~13 doc pages still describe role-hierarchy roll-up that ADR-0090 D3 removed.

---

Generated by Claude Code

[os-zhuang]

Decision, per object (the maintainer delegated this call on 2026-08-02; recording it here for implementers):

Object	Decision	Rationale
crm_contract	Option 2 — controlled_by_parent under the account (convert the already-required: true account lookup to masterDetail)	A contract is account data; hiding renewals from the very team the account is shared with defeats the point of territory/team sharing. crm_account is already required on every contract (contract.object.ts:50), so no backfill is needed. Cascade-delete is acceptable: account_protection already blocks deleting customers with open opportunities — extend it to active contracts in the same PR.
crm_quote	Option 2 — controlled_by_parent under the account, same conversion (quote.object.ts:68 is already required: true)	Matches the contract decision and extends the #547 line-item reasoning one level up (the chain becomes quote_line_item → quote → account). Resolves the 360° keyhole this issue reports. Pricing confidentiality is better enforced by discount governance (ceiling + approval — being filed as a batch-2 issue) than by row hiding; a rep who can see the account may see what was quoted on it.
crm_task	Option 3 — status quo (private)	Tasks are personal work items. The legitimate "what's happening on this account" need is an activity timeline need, met by the batch-2 activity-model issue — not by sharing to-do lists.
crm_opportunity (the "one level up" question)	Explicitly deferred	Stays own-only + the ≥$100k director rule until a territory/team model exists; revisit then. We accept the partial pipeline keyhole for now rather than mirror territory criteria per child object (the brittleness this issue itself warns about).

Sequencing: land after #548 Option B, so "own" evaluation is already trustworthy when the OWD changes. Once quotes/contracts go controlled_by_parent, the readScope: 'own' grants on them become parent-derived — test/authorization-coverage.test.ts's inert-scope and parent-resolution checks apply automatically, as noted in the issue body.

---

Generated by Claude Code