controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA)

[hotlong]

Part of objectstack-ai/hotcrm#706. Successor to #5493, which closed via merged PR #6909 ("fix(sharing): defer to an app-authored RLS widener before hard-refusing a by-id write").

Measured on @objectstack/* 17.0.0 GA during HotCRM's GA close-out sweep (hotcrm#1150 / #1152), real Bearer tokens against a running dev server.

What #6909 fixed, and what it did not

#5493's rc.2 symptom is gone: an app-authored RLS update-widener is now consulted on a direct by-id write to an object that carries sharing rules.

What still refuses is the derived write. crm_campaign_member is controlled_by_parent (ADR-0055) with master crm_campaign; its insert/update path first asks whether the caller may edit the MASTER. That check does not consult the master's RLS update policy — it resolves master editability through ownership and sys_record_share only. So the same principal, on the same master record, is simultaneously allowed to write the master and refused to write its children.

The isolation

One variable — who created the campaign. Everything else identical: same principal (marketing_user, which authors marketing_campaign_updates, an operation: 'update' RLS policy using: 'id != null' on crm_campaign), same objects, same payloads, same session.

step	campaign created by ADMIN	campaign created by MARKETING
1. PATCH the campaign itself (master, by id)	200	200
2. INSERT a child (crm_campaign_member)	403	201
3. UPDATE an admin-created child	403	200
4. control: admin updates the same child	200	200
5. security/explain update on the master, record-scoped	allowed=true	allowed=true

Row 1 shows the widener in force in both columns; row 5 is the platform's own verdict agreeing. Rows 2 and 3 nonetheless refuse in the left column with:

[Security] Access denied: insert on 'crm_campaign_member' requires edit access to its
master record (master 'crm_campaign' not editable by this user (record sharing))

So security/explain and the master-editability check disagree about the same record, the same operation, and the same principal — the parenthetical names record sharing as the deciding layer, which is the layer #6909 taught to defer on the by-id path.

Why it matters

For HotCRM this is the app's "Add to Campaign" enrolment path — marketing's core write surface. On rc.2 the child widener worked and the master one did not; on GA the two have swapped, so the user-visible workflow is broken in the mirror direction. The app's declaration is unchanged and correct: an object grant plus an RLS update widener that says "marketing works any campaign".

Reproduction

# marketing_user token; a campaign it neither owns nor created
PATCH /api/v1/data/crm_campaign/:id {"description":"x"} -- 200
POST /api/v1/data/crm_campaign_member {"crm_campaign":":id", "crm_lead":"...", "status":"sent"}
 -- 403, master not editable
# then repeat both against a campaign the same principal created -- 200 / 201

Suggested direction

Have the ADR-0055 master-accessibility resolution for WRITE consult the same composition #6909 installed on the by-id path, so "may I edit this master" answers identically whether it is asked directly or on behalf of a child.

Evidence: hotcrm#1152 probe 31-706-isolate.mjs, readings posted on hotcrm#706.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/plugins/plugin-security/ (the ADR-0055 master-accessibility resolution for WRITE; assertControlledByParentWrite and the record-sharing composition #6909 installed on the by-id path) ⇒ domain:identity. Type Bug, queued.

Rationale: routed by landing package. The isolation in the card is clean — one variable, five rows, with security/explain as the platform's own contradicting verdict (row 5) — so the defect is located, not inferred.

Not escalated: this narrows a divergence toward the platform's own already-shipped answer. security/explain and the by-id write path both say allowed=true; only the derived-write path disagrees. Making the two agree does not widen access beyond what #6909 already ruled admissible — it applies that ruling on the second call site. The governed-side meta-rule points the same way: one operation, two implementations, keep the one that composes the RLS widener.

⛔ Scope guard, load-bearing: the fix is to have the master-editability check consult the same composition, not to relax the check. If the dev finds that reaching parity requires widening what counts as master-editability beyond #6909's composition, that is a permission-boundary expansion — stop and report the fork, do not land it.

Hard serial: #8688 (queued this round, same lane, same guard). One dev in sequence, not two in parallel.

Size/model suggestion: M, opus.

---

Generated by Claude Code

[qq9340100]

Deferred this round on a same-file serial, not on merit — recording the reason so it is not re-derived

domain:identity seat, PM session session_01NaS1PAHJcPfAA2acnV53Tn, running the maintainer's direct channel (verbatim: 「identity ＋ services ＋ cli 优先处理 bug」). ⛔ Not claimed, ⛔ labels unchanged — this card stays pm:queue and is genuinely dispatchable the moment the serial clears.

This was the identity lane's top bug candidate this round (oldest bug + pm:queue + unassigned in the lane), and the premise re-verified clean on origin/main @ 3508678 before I set it aside:

• assertControlledByParentWrite is live at packages/plugins/plugin-security/src/security-plugin.ts:4815.
• Its record-sharing refusal is at :4896 — denyMasterEdit(\master '${rel.master}' not editable by this user (record sharing)`, masterId)`, byte-matching the parenthetical in the card's captured 403.
• The RLS leg sits immediately above at :4890, which is the asymmetry the card isolates.

So the card is not stale and needs no re-triage.

Why it is held

⚠️ #8613 is in flight and declares packages/plugins/plugin-security/src/ in its authorized file surface (claim comment 5294608710, re-dispatched 2026-08-14 14:42Z after a maintainer scope widening to packages/core + plugin-auth). Its declared reach into this package is the permission-set DB loader's where clause, as defence in depth — a different region of the same file this card must edit.

Region-level申报 would put the two at :616 vs :4815-4900, which looks disjoint. I am not treating that as sufficient: the same-file serial is the lane's default, the region-level exemption is the maintainer's to grant per-card and has not been granted here, and #8613 is an access-control card mid-implementation whose final surface is explicitly still moving (its own dispatch requires a stop-and-report on overlap). Racing an RLS-composition change into the same file against it is the shape that produces two individually-green changes that are wrong together.

Also hard-serial per triage: #8688, same lane, same guard — one dev in sequence, not two in parallel. That constraint is unchanged and applies to whichever of the two goes first.

Release order for the next identity round

1. sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 lands (or releases plugin-security from its surface).
2. Re-verify this card's file surface on the merged ref — sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 touches the permission-set resolution path, and "the merge that closes your blocker is the one most likely to have moved your card" applies directly here.
3. Then controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679 and A missing required master-detail parent still answers 422 MISSING_REQUIRED_FIELD with no fields[] and a [Security] message — while the same field, present-but-unresolvable, answers 400 VALIDATION_FAILED with fields[] (#7474 residual, 17.0.0 GA) #8688 in sequence, not in parallel.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 2 — the serial recorded at 16:05 is discharged
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8679-controlled-by-parent-master-rls
Worktree: objectstack-issue-8679
Domain: domain:identity
File surface: packages/plugins/plugin-security/src/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: #8613 MERGED as PR #8713, verified on origin/main @ 5f5e23424. That was the only thing holding this card — its declared surface included packages/plugins/plugin-security/src/, and I deferred this card at 16:05 rather than race an access-control change into the same file. plugin-security now carries no in-flight claim (git ls-remote shows no branch for #8679 or #8688).

⚠️ Premise re-verified on the MERGED ref, not the pre-merge one — and this is exactly why that step exists: the refusal I anchored on has moved, security-plugin.ts:4896 → :4908, because #8613 landed code above it. The line is intact and byte-identical (denyMasterEdit(\master '${rel.master}' not editable by this user (record sharing)`, masterId)`), so the card stands — but a dev grepping my earlier line number would have landed in the wrong place. Anchor on the symbol, never the line.

⚠️ #8613 changed the neighbourhood this card edits. It enforced active on sys_permission_set / sys_position at the core derivation seam plus the plugin-security DB loader as defence in depth. Re-read assertControlledByParentWrite and the record-sharing resolution on current main before assuming anything about their shape.

Hard serial still in force: #8688, same lane, same guard — one dev in sequence, not two in parallel. It stays pm:queue and unclaimed until this lands.

Dispatched under the maintainer's direct channel, verbatim instruction: 「identity ＋ services ＋ cli 优先处理 bug」.

---

Generated by Claude Code