`crm_opportunity_line_item` has no object-level CRUD grant in any app-crm permission set — the platform's own build lint already flags it

[os-zhuang]

What was measured

Building examples/app-crm (pnpm --filter '@objectstack/example-crm...' build)
emits an author-time warning nothing has acted on:

⚠ object "crm_opportunity_line_item": detail object "crm_opportunity_line_item"
 (master_detail "opportunity" → "crm_opportunity") has no object-level CRUD
 grant in any permission set. A master-detail child derives its RECORD-level
 access from the master (ADR-0055 controlled_by_parent), but object-level CRUD
 is a SEPARATE gate that is never derived — role-bound non-admin users are
 denied (403) before the parent-derived access is ever consulted (the silent
 "can't submit the subtable" trap).
 Grant "crm_opportunity_line_item" in at least one permission set that already
 grants its master "crm_opportunity" — e.g. permissions[i].objects.crm_opportunity_line_item
 = { allowRead: true, allowCreate: true, allowEdit: true }.
 rule: security-master-detail-ungranted at objects[5].fields.opportunity

examples/app-crm/src/security/sales-positions.ts declares the app's only
non-guest permission set (crm_sales_user) with grants on 5 objects
(crm_account, crm_contact, crm_opportunity, crm_lead, crm_activity)
— crm_opportunity_line_item is not among them, even though the object exists
specifically to be edited inline on the Opportunity form
(inlineEdit: 'grid', crm_opportunity_line_item.object.ts).

Confirmed live: objectstack verify --app examples/app-crm/objectstack.config.ts --rls (run against main after #8060 bound the app's three positions to
crm_sales_user) shows every position persona probe-blocked on exactly this
one object — LIST 403, object gate refuses before record scope is ever
consulted — while the other 5 granted objects resolve normally.

Why this is a real gap, not decoration

The build's own lint rule (security-master-detail-ungranted) names the
consequence precisely: any role-bound (non-admin) user — including one holding
sales_rep/sales_manager, the positions this app ships to demonstrate
selling — gets a silent 403 the moment they try to add/edit a product line on
an Opportunity, despite fully owning the parent record. The example ships
inlineEdit: 'grid' specifically to make line-item editing look like a normal
part of the Opportunity form; nothing in the UI would explain the resulting
403 to whoever hits it.

Suggested fix

Add crm_opportunity_line_item to crm_sales_user's objects map in
examples/app-crm/src/security/sales-positions.ts, e.g.
{ allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false }
— matching the grant shape already used for its parent crm_opportunity.

Not fixed here

Found while implementing #8060 (bind positions → crm_sales_user), which was
scoped to the missing sys_position_permission_set join only, per the
triage ruling — deliberately not the permission set's own grant contents.
Filed unassigned, unlabeled for triage.

[hotlong]

Triage: lands in examples/app-crm/src/security/sales-positions.ts — the subsystem this example exercises is the permission-set/security model, same lane as its sibling #8060 ⇒ domain:identity, type Bug, pm:queue. The platform's own build lint (security-master-detail-ungranted) both flags the defect and prescribes the fix, and the live objectstack verify --rls run confirms every position persona probe-blocked on exactly this object.

Size/model suggestion: S mechanical / sonnet. Acceptance: the build warning disappears and the same verify --rls run shows the line-item object resolving for the sales positions (grant shape matching the parent crm_opportunity, allowDelete: false as suggested). No dependency: #8060's fix is already on main per the card's measurement.

---

Generated by Claude Code

[os-zhuang]

os-dev-report

{
 "issue": 8164,
 "status": "done",
 "branch": "claude/issue-8164-crm-line-item-grant",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/8228",
 "premise_still_valid": true,
 "summary": "Granted crm_opportunity_line_item object-level CRUD in crm_sales_user (examples/app-crm/src/security/sales-positions.ts), matching its master crm_opportunity's exact grant shape ({allowRead, allowCreate, allowEdit: true, allowDelete: false}) since the object's access is meant to derive from its master per ADR-0055 and the lint rule's own name. Regenerated the ADR-0090 D6 access-matrix.json snapshot via `objectstack build --update-access-matrix` (a generated artifact, never hand-edited) to record the new grant with the object's own sharingModel (controlled_by_parent), which the build otherwise refuses as undocumented capability drift. Added one purely-additive test to smoke.test.ts.",
 "tests": "smoke.test.ts disposition: NEW test, purely additive (`git diff` on the file shows only one inserted `it()` block before the closing `});` -- no existing assertion touched, re-spelled, or rewritten). There was zero prior coverage of crm_sales_user's grant contents, so this is neither a re-spell, nor 'was asserting the bug', nor a red-to-green rewrite of an existing check -- it is coverage for a previously-untested surface. Confirmed it discriminates with an isolated ablation cycle (revert grant -> run test -> restore, via a script with a trap guaranteeing restore): ablated run gave `AssertionError: crm_opportunity_line_item has no object-level CRUD grant: expected undefined to be defined` (1 failed); restored run gave 28 passed (2 files), including this test. access-matrix.json disposition: GENERATED artifact (ADR-0090 D6), regenerated via `objectstack build --update-access-matrix`, never hand-edited; diff adds one entry for crm_opportunity_line_item with create/read/edit true, delete false, sharingModel 'controlled_by_parent' (the object's own OWD, not the master's public_read_write). `pnpm --filter @objectstack/example-crm test`: 28 passed (2 files). `pnpm --filter @objectstack/example-crm typecheck`: clean (tsc --noEmit, 0 errors). `objectstack verify --app examples/app-crm/objectstack.config.ts --rls` AFTER fix: each of the 3 position personas (sales_rep, sales_manager, finance_approver) -- objects:6, memberVisible:6, probeBlocked:0, holes:0; crm_opportunity_line_item flips from probe-blocked to member-visible (not proven -- expected per the caveat: the object's record scope follows a public_read_write master via controlled_by_parent, so the object gate opening makes it visible by design, not a cross-owner proof). Aggregate across positions: probeBlocked 0, memberVisible 18, holes 0. Base (non-position) persona: consistent:6, holes:0, proven:6, unchanged. Build lint AFTER fix: `security-master-detail-ungranted` does not fire (grep for the rule name in the build log: no match). ABLATION (predicted vs measured): predicted probeBlocked would return to 1 per persona (3 aggregate), memberVisible per persona would drop to 5, and the security-master-detail-ungranted warning would reappear verbatim as quoted in the original issue -- measured exactly that: each persona objects:6, memberVisible:5, probeBlocked:1 (aggregate probeBlocked:3, memberVisible:15, holes:0 both before and after); build lint reproduced the rule at `objects[5].fields.opportunity` with the same message as the issue body. Restored via `git checkout HEAD -- examples/app-crm/` from the already-committed fix (never git stash); confirmed `git status --porcelain` empty and `git diff HEAD --stat` empty after restore. Gates (from repo root, after a full `pnpm build` closure, per the analytics-reconcile reachability trap): `pnpm check:type-check-debt` -- OK, 33 ledger entries re-measured, 1966 raw tsc errors total, NONE above recorded ceiling (the workspace-root entry, which reaches examples/app-crm via scripts/analytics-reconcile/app-crm.ts, held at its recorded 80 once the closure was genuinely complete -- an earlier partial-closure measurement spuriously showed +4, traced to 4 unbuilt showcase connector packages unrelated to this diff, resolved by completing the build rather than touching the ledger); several info-level entries sit below their ceiling and were left alone per instructions (pre-existing, not mine to close). `pnpm check:query-options-erasure` -- OK, 67 unswept non-test sites in 17 files, none new. `pnpm check:engine-double-contract` -- OK, 175 pinned, 133 in DEBT ledger, 2 exempt, no drift (this PR adds no fake engine). `pnpm check:nul-bytes` -- OK, 7443 files scanned, no raw control bytes. Post-merge (merged origin/main into the branch before push; verified zero commits since fork touched examples/app-crm/ at all, so no real conflict risk): rebuilt @objectstack/spec (moved in the merge) and ran `pnpm --filter @objectstack/spec check:generated` -- all 13 generated artifacts up to date; rebuilt example-crm's dependency closure against the fresh spec and re-ran its test + typecheck -- clean.",
 "open_questions": [],
 "out_of_scope_findings": [
 "filed as #8231: i18n -- 24 form/page sections across examples/app-crm and examples/app-showcase declare a label but no name (translation-section-name-missing fires on every build, unacted on since the rule landed in #5417); observation-class, unassigned, finding label, no pm:queue"
 ]
}

---

Generated by Claude Code