Grid/list columns offer a sort header on `formula` fields, which the server refuses as of framework#6994

[os-zhuang]

Filed from framework#6994's implementation. Recorded, not claimed.

What changes underneath

framework#6994 makes the list path refuse an orderBy naming a formula field: 400 INVALID_SORT. Until now that sort was silently dropped — the server answered 200 with every row present in arbitrary order (asc and desc byte-identical, measured on a real SqlDriver), because a formula field is virtual: no driver materialises a column for it, so the ORDER BY reached 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

ObjectGrid disables the sort affordance only for reference-bearing types:

packages/plugin-grid/src/ObjectGrid.tsx:1771

return isExpandableFieldType(fieldDef) ? { ...col, sortable: false } : col;

and isExpandableFieldType (packages/core/src/utils/expand-fields.ts:42) covers lookup / master_detail / tree / user only. formula is 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: false for columns whose field type materialises no column — formula today. 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 RelatedList and the other data-table renderers derive sortable through 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).

[claude]

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 sortable derivation 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:1771 still gates sortable: false on isExpandableFieldType alone, and expand-fields.ts's EXPANDABLE_FIELD_TYPES still covers only the reference-bearing types — formula keeps 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: false for 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 / #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 #6994, this becomes a user-clickable 400 on any rendered formula column — worth that seat's own target:v17 judgment.

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

---

Generated by Claude Code