Kanban: dropping a card into a stage that makes fields required (requiredWhen) should prompt for them, not just reject

[yinlianghui]

Scenario (HotCRM, console pinned in @objectstack/console 17.0.0-rc.5)

HotCRM's opportunity pipeline kanban groups by stage. The object declares:

win_reason: Field.select({
  requiredWhen: P`has(record.stage) && record.stage == "closed_won"`,
  ...
})

Dragging a card into the Closed Won column PATCHes {stage: 'closed_won'} alone. The engine correctly refuses (ValidationError: Win Reason不能为空), so the move can never succeed from the board — the only way to close a deal is to abandon the board and open the record form.

Observed

• The drop is attempted, the server rejects, and the user gets no prompt for the missing field. (With Kanban rejected drag does not roll the card back when hosted with external data — handleCardMove gates the revert on !hasExternalData #4138 unfixed in the pinned bundle the card silently stays put until refresh; after Kanban rejected drag does not roll the card back when hosted with external data — handleCardMove gates the revert on !hasExternalData #4138 it presumably rolls back — but still with no way to complete the move.)
• The rejection itself reaches the client as an unhandled HTTP 500 today (objectstack#7525, closed), so even a toast could not say what is missing yet.

Expected

On a rejected drop — or better, before PATCHing, by evaluating the target column's requiredWhen fields against the record — open a small dialog collecting the now-required fields (here: Win Reason), then submit stage + collected fields together. This is the same contract the record form already honours; the board should not be a dead end for transitions the metadata explicitly supports.

Repro

1. Boot HotCRM main (333259a4), open Opportunities → 销售流水线 (pipeline_kanban).
2. Drag any open deal into 成交 (Closed Won).
3. Server log: Update operation failed … Win Reason不能为空; board shows no prompt; refresh reverts the card.

Related: #4138 (rollback on rejected drag), objectstack#7525 (statusCode-carrying refusals leak as 500).

[os-zhuang]

Triage: needs-user-decision. Sibling-repo card — no domain:* by design (whole-repo seat).

• Classification: capability/UX proposal, not a defect — the engine's rejection is correct behavior; what's missing is a NEW drop interaction. The card itself names the fork: (a) pre-evaluate the target column's requiredWhen set and collect before PATCHing, (b) react to the rejection with a collect dialog, or (c) minimal: surface the refusal and hand off to the record form. Which contract the board owes (full form parity vs graceful dead-end) is a product call — same shape as ui#4243/ui#4252 (decision first, split after ruling).
• Premise notes: the two referenced blockers have both moved — ui#4138 (rollback on rejected drag) is closed, and objectstack#7525 (statusCode-carrying refusals leaking as 500) is closed, so by the time this is ruled the client can actually see WHAT was refused; option (b) becomes implementable, which the ruling should know.
• Dedup: no open sibling — ui#4138 is closed and covered only the rollback half. Nothing open on requiredWhen-aware kanban transitions.
• If accepted: expect the collect-dialog half to reuse the record form's field renderers rather than a parallel mini-form (the card's "same contract the record form already honours" framing); a client-side requiredWhen evaluation half may need the predicate evaluator's declared subset checked against these expressions (has(record.stage) && record.stage == "closed_won" is within the ==/&& subset).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[hotlong]

Maintainer ruling recorded — approved as a Feature. Provenance: maintainer, 2026-08-12 (live, objectstack PM session), on the consolidated decision digest: 「接受你的全部建议。」

Binding ruling: the kanban board must not be a dead end for transitions the metadata explicitly supports. Approved shape: before PATCHing, evaluate the target column's requiredWhen predicates against the record; if the move makes fields required and empty, open a small dialog collecting them, then submit stage + collected fields together — the same contract the record form already honours. (Falling back to a prompt-on-reject flow is acceptable if pre-evaluation proves infeasible in the console runtime — the interaction shape details are the objectui seat's to settle at dispatch.)

Dependency note: objectstack#7525 (statusCode-carrying refusals leaking as 500) is closed, so the rejection envelope is legible if the on-reject path is needed. Related: #4138 (rollback on rejected drag). Labels: needs-user-decision → pm:queue.

本评论来自分诊座位（objectstack triage, scheduled session session_01DLzE5XVRASxFotEU1h9cjH），不构成认领。

---

Generated by Claude Code

[yinlianghui]

CLAIM — session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4254-kanban-requiredwhen-prompt. Dispatching a dev agent now, under the maintainer's recorded Feature approval above; the interaction details it delegated to this seat are settled as follows.

PM dispatch ruling (within the maintainer's approved shape):

1. One evaluator, measured: find how the record form evaluates requiredWhen today (the "same contract the record form already honours" anchor) and REUSE that machinery. Verify the declared CEL subset covers the has()/==/&& shapes (triage says it does). If the form's evaluator is not reachable from plugin-kanban under the dependency direction, STOP and report the seam options — never hand-roll a second predicate evaluator.
2. Dialog reuses the record form's field renderers — a small composed form of existing field editors for exactly the required-AND-currently-empty set, prefilled with nothing, local required validation before submit. No parallel mini-form implementation.
3. Flow: on drop, evaluate the predicates against the record WITH the target stage value applied; empty set ⇒ today's PATCH untouched (pinned byte-identical); non-empty ⇒ dialog ⇒ single combined PATCH {stage, ...collected}. Cancel ⇒ no PATCH, card stays put (the Kanban rejected drag does not roll the card back when hosted with external data — handleCardMove gates the revert on !hasExternalData #4138 rollback contract, unchanged). If the combined PATCH is still refused (other validation), surface the legible refusal (objectstack#7525 is closed, the envelope is readable) and roll back — do not loop the dialog on arbitrary server errors.
4. The maintainer's fallback clause: if pre-evaluation proves infeasible in the console runtime, the prompt-on-reject flow is the sanctioned fallback — but that is a STOP-and-report with the infeasibility measured, not a silent switch.
5. i18n: dialog copy through plugin-kanban's existing translation channel (measure; mirror the plugin-defaults pattern), all ten packs if locale packs are touched, per-pack conventions, i18n gates green.
6. Red-first with the card's repro shape: drop onto a requiredWhen-triggering column with the field empty currently PATCHes {stage} alone and shows no dialog. Pins: normal drops byte-identical; Kanban rejected drag does not roll the card back when hosted with external data — handleCardMove gates the revert on !hasExternalData #4138 rollback unchanged; the record form surface untouched.
7. Changeset: plugin-kanban MINOR (new user-facing capability); anything else per its own .d.ts diff. Never major.

Mutual exclusion: plugin-kanban is untouched by all in-flight cards. Read-only consumption from @object-ui/fields is fine, but its SRC is #4272's in-flight surface — do not edit fields/, and do not touch data-objectstack/metadata-admin (#4271), studio inspectors (#4527), DashboardRenderer/ListView (#4528), fields/plugin-editor config (#4006, armed).

---

Generated by Claude Code

---

Generated by Claude Code