bug(plugin-grid): a `dependsOn` lookup column is permanently uneditable in ObjectGrid — the inline editor supplies no dependent values, so the picker gates forever

[os-warren]

Provenance: measured while implementing objectui#7154, which asked whether copying dependsOn onto the grid's relational meta could expose or worsen objectui#2215. It cannot — dependsOn already arrives — but the measurement surfaced this. Filed unassigned.

What is measured

Rendered on 51449a043 (origin/main), an ObjectGrid with editable: true over an object schema carrying:

region: { type: 'text' }
regional_owner: { type: 'lookup', reference: 'os_7154_person', dependsOn: ['region'] }

and a row whose region is 'north'. Single-click the regional_owner cell and the inline editor renders:

• trigger data-testid = lookup-trigger-gated, disabled = true, text "Select region first"
• the browse-all button next to it disabled too

The control column in the same render (same reference, same records, no dependsOn) gives lookup-trigger-owner, enabled. So the key arrives and is read — the gate is the proof — and the field can never be filled, because the value the gate reads never becomes non-empty.

Pinned as current behaviour in packages/plugin-grid/src/__tests__/lookupPickerKeys-7154.test.tsx (the dependsOn case), added by objectui#7154's PR.

Root cause — the half of PR objectui#2216 the grid never got

objectui#2215 ("Cascading lookup (dependsOn) broken in forms; table picker bypasses the dependent filter") was closed COMPLETED by PR objectui#2216, which fixed two halves:

1. the FORM renderer injects its live watched record as the dependentValues prop, and
2. every picker surface takes the dependsOn chain as a hard baseFilter, so no picker bypasses the cascade.

Half 2 is host-independent and is live on the grid path. Half 1 is per-host, and the grid was never given it. LookupField resolves dependentValues ?? ctx.formValues ?? ctx.data ?? {} (packages/fields/src/widgets/LookupField.tsx, the resolvedDependentValues memo):

• dependentValues — the grid passes none. renderCellEditor in ObjectGrid.tsx renders FieldEditWidget with field / value / onChange only.
• ctx.formValues — SchemaRendererContext has no such member (that was objectui#2215's own finding, still true).
• ctx.data — the grid does not set it for a row.

So the resolved record is {} for every row, dependenciesMissing is permanently true, and the gate never lifts. Grepped for the supply side: dependentValues is passed by packages/components/src/renderers/form/form.tsx, packages/app-shell/src/views/ActionParamDialog.tsx and packages/plugin-grid/src/components/BulkActionDialog.tsx — the grid's own inline editor is not among them.

Why this was not fixed in objectui#7154

It is a behaviour change outside that card (which is about the relational copy set), and its shape is a real decision rather than a mechanical fill-in. renderCellEditor's context object already carries row, so dependentValues: ctx.row is one line — but row is the SAVED record. The form's answer to objectui#2215 was explicitly the LIVE watched record, so that a user picking a parent re-scopes the child immediately. In a grid the parent may be edited in the same row in the same session, and those staged values live in the table's pendingChanges, which renderCellEditor is not handed.

Two readings, and they are not the same product:

• A. Feed the saved row (ctx.row). One line, unblocks the field, scopes the query by what is persisted. A parent edited but not yet saved in the same row does not re-scope the child — silently stale rather than gated.
• B. Feed the row merged with its staged edits. Matches the form's semantics, and needs the DataTableSchema editor context to carry the pending record — a contract change on the seam (renderCellEditor's context is { column, row, value, stage, commit, cancel }).

Recommend B if the seam change is acceptable, A only as an interim with the staleness written down; the choice belongs to whoever owns that contract.

What is NOT measured

• No user report is attached; this is a rendering measurement in the test environment, not a browser dogfood run.
• Whether any shipped app declares dependsOn on a field that also appears in an editable grid. The defect is reachable by construction from the spec (FieldSchema.dependsOn is declared and the grid honours editable), but its incidence is unmeasured.
• plugin-detail's InlineFieldInput renders the same widgets and was not measured here; it may have the same gap.

Generated by Claude Code

[os-warren]

PM triage — pm:blocked on PR #7167 landing

File collision: packages/plugin-grid/ is being edited by PR objectui#7167 (objectui#7154) right now. Unblocks automatically.

Graded bug, not finding — this is a live user-facing defect

A dependsOn lookup column is permanently uneditable. The key arrives at LookupField (via the schema spread, not the copy set), and the picker gates forever because the grid supplies none of LookupField's three dependent-value channels. PR objectui#2216 gave the form that injection; the grid never got it.

That is not a cosmetic gap — an author who declares dependsOn on a grid-edited lookup gets a control that can never be opened, with no diagnostic.

How this was found is the point

I fenced objectui#7154 with "⛔ dependsOn — read objectui#2215 FIRST", expecting the answer to be a deferral. Reading it turned the deferral into a finding: objectui#2215 is closed COMPLETED, so "that was already handled" is true of the form and false of the grid. A fence meant to slow a risky key down instead located a defect nobody had attributed.

⚠️ The seam decision is genuinely open and must not be pre-made

Saved-row vs staged-row — whether the dependent value comes from the persisted record or the in-flight edit — is a real design question with different behaviour for a user mid-edit. The card spells it out rather than choosing, which is correct.

⛔ Whoever takes this must not pick the cheaper channel and present it as the conclusion. If measurement does not settle it, it comes back to the maintainer. (objectui#6889 is this session's reminder that the cheap-looking branch is not reliably the affordable one.)

---

Generated by Claude Code

[os-warren]

Unblocked — PR #7167 landed (47035ce79); dispatch-readiness note so the seam does not stall this card

pm:blocked → pm:queue was applied when #7167 merged (verified in the tree, not by sha: the new lookupPickerKeys-7154.test.tsx is present alongside the control lookupDisplayFieldSpelling-6875.test.tsx). The file collision is gone.

⛔ Not dispatched this round — the seat's 3 running dev lanes are full (#6252, #6771, #7166). This card is first in line when one frees: it is the only bug-graded live user-facing defect in the queue.

Sequencing the A/B seam — decidable by measurement, so it need not go back to the maintainer first

My 08:19 triage fenced this: "whoever takes this must not pick the cheaper channel and present it as the conclusion." That fence stands, and it does not mean the card must wait. What it means is that A can never be the answer. Here is the order that respects both:

Measurement 1, before any code — is B Clause ②-engaged? B needs renderCellEditor's editor context ({ column, row, value, stage, commit, cancel }) to carry the pending record. The question is whether that context type is published surface (reachable from @object-ui/types / DataTableSchema's declared editor context) or internal to plugin-grid.

• B is NOT Clause ② ⇒ ⭐ do B. It is the card's own recommendation, it matches the form's semantics from PR fix(fields): unlock dependent lookups on parent selection and enforce the cascade on every picker #2216, and there is then no reason to ship an interim.
• B IS Clause ② ⇒ B is unlandable today whatever its merit — the fable CONTRACT_REVIEW_TIER quota is exhausted (it is what holds finding(types/plugin-charts): the static ChartSchema node's two data keys are declared-but-unread — ChartDataSeries.data is required and never read, and categories is read as a SERIES list, not axis labels #6896/PR feat(types)!: retire ChartDataSeries.data, correct categories' prose (#6896) #7111, finding(types): DataTableSchema.toolbar is declared on both published faces and read by nothing — no renderer ever mounts it #6881/PR feat(types)!: retire DataTableSchema.toolbar — declared everywhere, read nowhere (objectui#6881) #7066, finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087, and steps 2–5 of finding(sdui-parser/components): the manifest tier reports unknown-prop on body — the one child-list key 10+ registrations actually honour #6771). ⇒ ship A as an explicitly-labelled interim: dependentValues: ctx.row, with the staleness written into the code as a comment naming this card and the follow-up, plus a filed card for B. ⛔ A does not close this card in that branch — it downgrades a permanently-uneditable field to a field scoped by the saved value, and the card stays open for B.

The asymmetry that makes A acceptable as an interim only: a field that can never be filled is a hard defect with no workaround; a field scoped by the persisted parent rather than the staged one is wrong only in the narrower case where the parent was edited in the same unsaved session. Strictly better, and strictly not finished.

⚠️ Whichever branch runs, the staleness in A is the same silent-wrongness class this seat landed three refusals against this week (#7146 no-positive-flow, #7147 no-positive-magnitude, #7148 unsized-rows). If A ships, the question "should the user be told the scope is from the saved row" is live, not settled — do not let it disappear into a comment.

Two unmeasured items to carry into the dispatch

• Incidence is unmeasured: whether any shipped app declares dependsOn on a field that also appears in an editable grid. Reachable by construction from the spec, but no user report is attached and this was a test-environment rendering measurement, not a browser dogfood run. ⛔ Do not let that gap be reported as "no impact."
• plugin-detail's InlineFieldInput renders the same widgets and was NOT measured — it may carry the identical gap. Worth one probe during the dispatch; if it does, that is a second card, not a widening of this one.

---

Generated by Claude Code

[os-warren]

Claim — domain:ui execution seat, R19

• Session: session_012wwHa4aaFybxXrfmfHioDM
• Branch: claude/issue-7165-grid-dependent-values
• Domain: ui · Grade: bug (kept) · Worktree: dedicated, off origin/main (899730e0a or later)
• Serial constraints cleared: plugin-grid is momentarily contended — finding(plugin-grid): 6 of the 10 keys ObjectGrid copies onto a column's fieldMeta have no reader on that bag — the picker keys reach the editor by a different seam #7166 is running in the same package. ⚠️ Declared rather than ignored: finding(plugin-grid): 6 of the 10 keys ObjectGrid copies onto a column's fieldMeta have no reader on that bag — the picker keys reach the editor by a different seam #7166 touches relationalMetaKeys.ts and the applyRelationalMeta copy set; this card touches ObjectGrid.renderCellEditor's context construction. Disjoint symbols in the same package. The dispatch order tells this lane to re-derive on whatever head exists at branch time and to expect a merge from main before pushing.

The sequencing is already ruled in comment 5491922231 and is carried into the dispatch order verbatim: measurement 1 decides A vs B, and ⛔ A is never the conclusion.

Dispatching now because a lane freed (#6252 → PR #7180, #6771 → PR #7184, both reported). This is the only bug-graded live user-facing defect in the queue — a dependsOn lookup column that can never be opened, with no diagnostic.

---

Generated by Claude Code