Repository navigation
回归:#547 实测通过的 marketing_campaign_updates RLS 写扩权在 rc.2 上失效(403);同 PR 的 campaign_member 扩权仍工作 #706
Description
Found during the 17.0 GA acceptance sweep on @objectstack/* 17.0.0-rc.2 (current main), permission matrix phase. This is a regression against a behavior #547 explicitly runtime-verified.
Then vs now
#547 added two RLS update-wideners so marketing's declared campaign grants would be real, and its PR body records the runtime verification: campaign-member insert as marketing_user → 201.
rc.2 measured, marketing_user with its own token:
| Widener | rc.2 behavior |
|---|---|
marketing_campaign_member_updates |
✅ works — PATCH on an admin-owned member and on an owner_id-NULL member both → 200 (control: sales_rep → 403) |
marketing_campaign_updates (crm_campaign) |
❌ regressed — PATCH on a not-own campaign → 403 "FORBIDDEN: insufficient privileges to update crm_campaign …" |
Note the error shape: the failing denial is the sharing-middleware FORBIDDEN, not the row-gate's "[Security] … (row-level security)" shape that all other write denials in the sweep produced. That suggests the failing layer answers before RLS evaluation on objects that carry sharing rules — i.e. the widener never gets consulted on crm_campaign, while on crm_campaign_member (no sharing rules of its own) it does.
Impact
Marketing cannot edit campaigns they didn't personally create — the exact posture #547 was written to fix. Enrolment (member writes) still works, so the symptom is subtle: members move, the campaign itself is frozen.
Reproduction
# as marketing_user-bound user
PATCH /api/v1/data/crm_campaign/<admin-owned id> {"description":"x"}
→ 403 FORBIDDEN: insufficient privileges to update crm_campaign <id>
PATCH /api/v1/data/crm_campaign_member/<admin-owned id> {"status":"responded"}
→ 200Attribution
Platform (ordering of sharing middleware vs RLS wideners on objects with sharing rules), given one widener works and the other — identical in mechanism, different only in the object's sharing-rule presence — does not. The CRM declarations are unchanged since #547.
Evidence: acceptance run w4/results.jsonl (M5). Refs #547 #705
Activity
docs(acceptance): finalize — permission matrix does not hold; all 8 s…
yinlianghui commentedon Aug 5, 2026
Blocked-by: objectstack-ai/objectstack#5493
分诊(PM 循环第 1 轮,会话
session_01VHrPAGEgFDoHjphqYG4BMa):判定为平台缺陷(带 sharing rules 的对象上,sharing middleware 先于 RLS 扩权应答 —— 错误形状即证据),⛔ 不在 hotcrm 侧修。已立镜像单 objectstack#5493。CRM 声明自 #547 起未变、无需改动。本单打pm:blocked。Generated by Claude Code
hotlong commentedon Aug 14, 2026
GA re-probe — the named symptom is gone, but the defect survives with its direction inverted. Staying open.
Version:
@objectstack/*17.0.0 GA, repo atd4ddee0,objectstack dev -p 4001, real Bearer tokens. Mirror objectstack#5493 closed via merged PR objectstack#6909, "fix(sharing): defer to an app-authored RLS widener before hard-refusing a by-id write".Read the PR title closely — by-id write. That is exactly as much as GA fixed.
The two wideners have swapped states
marketing_campaign_updates(crm_campaign)marketing_campaign_member_updates(crm_campaign_member)So this card's literal claim — "the campaign widener regressed while the member widener still works" — no longer reproduces. Its inverse now does, and the user-visible workflow the card exists to protect is still broken. The GA refusal:
on a campaign the same principal had just successfully PATCHed.
The isolation — one variable, everything else held constant
Same principal (
marketing_user), same objects, same payloads, same session. The only thing that changes between columns is who created the campaign.security/explainupdate on the campaign, record-scopedallowed=trueallowed=trueRow 1 shows the RLS widener in force in both columns. Row 5 is the platform's own layer-by-layer verdict agreeing —
object_crud: grants, andallowed=truefor update on that specific record. Rows 2 and 3 refuse anyway in the left column, blamingrecord sharing.Two subsystems therefore disagree about the same principal, the same record and the same operation: the by-id write path defers to the widener (post-#6909), and the ADR-0055
controlled_by_parentmaster-editability check does not — it resolves master editability through ownership andsys_record_shareonly.Controls
sales_repPATCH on the same campaign (nocrm_campaignedit grant at all) — 403 object-level. So "campaigns became writable by anyone" is excluded; row 1's 200 is the widener.marketing_userDELETE on the campaign (allowDelete: false) — 403. The widener namesoperation: 'update'and widens nothing else.Impact on this app
marketing_campaign_member_updatesand the enrolment path are marketing's core write surface —src/actions/lead.actions.ts's "Add to Campaign" insertscrm_campaign_memberrows, andmarketing-user.profile.tsdocuments precisely this dependency: "enrolling a member is a write DERIVED from the campaign (controlled_by_parent), so it requires campaign edit at the row level." On GA that insert is refused for every campaign a marketing user did not personally create. On rc.2 it worked. Relative to rc.2 this is a regression on the member path, even as the campaign path was repaired.Disposition
Staying open,
pm:blockedretained — still blocked on the platform, and the CRM declarations remain unchanged and correct since #547.Mirror filed: objectstack-ai/objectstack#8679, as the successor to the closed #5493, carrying the isolation table above. Nominated for
target:v17on objectstack-ai/objectstack#8667 — nomination only; no label applied and the first-batch list untouched (#1150: "Seat A decides nothing").A note for re-triage: this card's title and body now describe a state that no longer exists. Whoever picks it up may prefer to re-title it around the surviving defect rather than read the rc.2 table as current.
Probes:
30-706.mjs,31-706-isolate.mjs— throwaway scaffolding, deleted. Executed under #1152 (GA close-out sweep #1150, group 3).Generated by Claude Code
Generated by Claude Code
hotlong commentedon Aug 14, 2026
Closed — moved upstream to objectstack-ai/objectstack#8679
Dispositioned under the transfer sweep #1156 (part 2). Maintainer ruling, 2026-08-14, quoted verbatim and untranslated:
and for the hotcrm side of a transferred card, the same ruling: 「关掉,只留指向镜像的指针」. Authority: #1156.
The mirror — verified before this close, not assumed
objectstack-ai/objectstack#8679 — "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)". Confirmed open, labelled
bug, and carrying this card's defect rather than a similar-sounding one: it reproduces the same five-row isolation table, the same principal, and the same refusal string namingrecord sharingas the deciding layer.The reading this close rests on
The GA re-probe already on this card — comment of 2026-08-14,
@objectstack/*17.0.0 GA atd4ddee0. Its finding, restated so this close is readable without following the link: the rc.2 symptom in the title above is gone (thecrm_campaignwidener now answers 200), but the defect survives with its direction inverted — the ADR-0055 master-editability check refuses a derivedcrm_campaign_memberwrite on a master the same principal has just successfully PATCHed, andsecurity/explainanswersallowed=truefor that exact record and operation.That inversion is why the close is a transfer and not a non-reproducer: the user-visible workflow this card exists to protect ("Add to Campaign" enrolment) is still broken, and it is still broken in the platform.
Why it closes here
The fix is the ADR-0055 master-accessibility resolution deferring to the same composition #6909 installed on the by-id path. That is platform source. The CRM declarations are unchanged and correct since #547, so there is no producer in this repo to change — the condition under which the ruling above sends a card upstream.
Label note:
pm:blockeddropped in the same write. It recorded a block on objectstack#5493, which is closed as completed via merged PR objectstack#6909 — the blocker it named has landed. The successor block is now #8679 and is tracked there; a closed card should not wear a stale blocker pointing at a merged fix.bug,prio:p1andupstream:objectstackare left as they were.Nothing is lost by this close: #8679 is open, carries the full isolation table and reproduction, and is readable without any hotcrm context.
Generated by Claude Code
Generated by Claude Code