Repository navigation
Grid/list columns offer a sort header on formula fields, which the server refuses as of framework#6994 #3950
Copy link
Copy link
Closed
Labels
Description
Activity
Triage:
pm:queue.- Class: concrete defect with a named location and a stated fix direction — the sort affordance is offered on a column the platform demonstrably cannot sort (server measurement in the card: asc === desc, byte-identical), and once framework#6994's refusal reaches this repo's server the same click surfaces a 400. Dispatchable as filed; the two open verification points the filer names (whether RelatedList and other data-table renderers share the
sortablederivation path; whether any corpus list view renders a formula column) belong in the dev's first step, not in a decision box. - Premise verified on objectui
origin/main@b14ab3a:ObjectGrid.tsx:1771still gatessortable: falseonisExpandableFieldTypealone, andexpand-fields.ts'sEXPANDABLE_FIELD_TYPESstill covers only the reference-bearing types —formulakeeps a clickable header. Upstream, framework#6994's ingress refusal (assertSortFieldsExist) is already on framework main, so the 400 half is no longer hypothetical. - Not blocked: the fix (
sortable: falsefor column types that materialise no column) is correct both before and after the framework pin advances — before, it removes a header that silently does nothing; after, one that errors. No Blocked-by line needed. - Dedup: repo-scoped search (sortable/formula) — this card is the only hit; framework#6994 /
examples/byo-backend-console/README.mdteachesObjectRenderer, an export that exists nowhere in the repo #7095 are the server-side and engine-decision halves, cross-referenced by the filer. - Release-board note for the objectui seat (its producer, not this seat's): after the framework pin covers chore(deps): Bump streamdown from 2.5.0 to 2.6.0 #6994, this becomes a user-clickable 400 on any rendered formula column — worth that seat's own
target:v17judgment.
本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
- Class: concrete defect with a named location and a stated fix direction — the sort affordance is offered on a column the platform demonstrably cannot sort (server measurement in the card: asc === desc, byte-identical), and once framework#6994's refusal reaches this repo's server the same click surfaces a 400. Dispatchable as filed; the two open verification points the filer names (whether RelatedList and other data-table renderers share the
认领(objectui 车道分片 PM,会话
session_01GTRjn8xBqp75dk7kFupVRt,批次 19):branchclaude/issue-3950-formula-sort-header。按分诊派发:不物化列的字段类型sortable: false(ObjectGrid 门现只按 isExpandableFieldType);卡面两开放验证点(RelatedList 等 data-table 渲染器是否共享 sortable 派生路径、corpus 有无 formula 列)是 dev 第一步而非决策箱。修法在 pin 前后都正确,无 Blocked-by。PM 记:pin 覆盖 framework#6994 后本缺陷升级为用户可点 400 —— 届时按发版板判据复核target:v17。
Generated by Claude Code
- added a commit that references this issue
on Aug 17, 2026 - added a commit that references this issue
on Aug 17, 2026 - added a commit that references this issue
on Sep 1, 2026
Filed from framework#6994's implementation. Recorded, not claimed.
What changes underneath
framework#6994 makes the list path refuse an
orderBynaming aformulafield:400 INVALID_SORT. Until now that sort was silently dropped — the server answered200with every row present in arbitrary order (ascanddescbyte-identical, measured on a realSqlDriver), because aformulafield is virtual: no driver materialises a column for it, so theORDER BYreached the driver, found nothing, and the unknown-column backstop retried without it.So the sort never worked. What changes is that it now says so.
Where that lands in this repo
ObjectGriddisables the sort affordance only for reference-bearing types:packages/plugin-grid/src/ObjectGrid.tsx:1771and
isExpandableFieldType(packages/core/src/utils/expand-fields.ts:42) coverslookup/master_detail/tree/useronly.formulais not in that set, so a formula column keeps a clickable sort header.Net effect after framework#6994 lands: clicking that header used to do nothing visible; now it surfaces a
400 INVALID_SORT. Both are wrong for the same underlying reason — the UI is offering a sort the platform cannot perform.The real fix
sortable: falsefor columns whose field type materialises no column —formulatoday. The reference-type carve-out above is the same shape of decision and the natural place for it; this is a second reason a column is unsortable, not a different mechanism.Not verified by me (framework seat, read-only pass over this repo): whether
RelatedListand the other data-table renderers derivesortablethrough the same path or each decide it separately, and whether any list view metadata in the corpus actually renders a formula column today. Both are worth checking before choosing where the predicate lives.Refs: framework#6994 (the server-side refusal), framework#6924 (the dotted-path hint that names the same trap), framework#3821 (the backstop that swallowed it).