Repository navigation
record:related_list has no groupBy, and its columns cannot cross a lookup — the two things a related list needs to stop being a flat strip of rows #7301
Description
Two authoring limits met on the same component while building a record page over sys_user (objectstack-ai/duly#13). Both are expressiveness gaps rather than defects — nothing renders wrong, the page just cannot say the thing.
1. No grouping
RecordRelatedListProps declares columns, sort, filter, limit. There is no groupBy, and RelatedList draws its own table rather than a list view, so the grid's grouping block (which does support nested levels with per-level collapse, and which this same app uses on a duly_duty list view) is unreachable from a related list.
The requirement was "their governed duties, grouped by frequency, so a monthly rhythm reads differently from an annual one". The closest authorable thing is putting frequency first in columns and first in sort, which makes each rhythm a contiguous block. It reads acceptably and it is not grouping — no group headers, no counts per group, no collapse, and the ordering is alphabetical (annual, daily, fortnightly, monthly, …) rather than by cadence.
Since grouping already exists and is already implemented for grids, the ask is mostly plumbing: let a related list accept the same block.
2. Columns cannot cross a lookup
RelatedList resolves lookup labels (it batch-fetches display names for FK cells) but has no dotted-path column support — columns: ['assignment.assigner'] names nothing.
Concretely: the page needed "assigned work, showing who assigned each". The task carries assignment (an FK); the assigner is duly_assignment.assigner, one hop on. So the column can show which assignment the task came from but not who raised it, and the reader has to click through.
The other route to the same value — a related list on duly_assignment itself, bound on its multi-value assignees field — is closed for an unrelated reason (filed separately as #7299), so on this page the requirement could not be met at all.
Given the label-resolution machinery is already there, a columns: ['assignment.assigner'] that expands the lookup one level would cover most of what related lists need; deeper paths can stay refused.
Neither is urgent on its own. Filed because both were hit inside one component on one page, and together they are the difference between a related list and a report.
🤖 Generated with Claude Code
Activity
os-zhuang commentedon Sep 5, 2026
分诊 —
domain:ui/priority:p3/pm:blocked/enhancement锚定 (anchoring)：渲染落点是
packages/plugin-detail/src/RelatedList.tsx⇒domain:ui。与 #7300 同理，两个新键都要先在上游@objectstack/spec的RecordRelatedListProps上有位置（packages/types/src/record-components.ts:94明写 "Aligned with @objectstack/spec RecordRelatedListProps"）。在
origin/maina472b07上复核的锚点RecordRelatedListProps的完整已声明键，逐个读出来（不是抽样）：groupBy不在其中 —— 在packages/types/src/record-components.ts全文 grepgroupBy：0 命中。正控制：同一次读里columns/sort/filter/limit全部命中。所以卡片第 1 条的前提（"declarescolumns,sort,filter,limit，没有groupBy"）是实测的完整枚举，不是分页窗口里的观察。卡片第 2 条（列不能跨 lookup）与 #7299 的复核相互印证：
RelatedList.tsx自己画表而不是走 list view，:516/:586两处 filter 合成都只认平铺字段名，全文无点号路径解析。定级理由
priority:p3—— 采纳卡片自己的定性并复核为真："Both are expressiveness gaps rather than defects — nothing renders wrong."frequency放columns首位 +sort首位，各节奏成为连续块。卡片诚实地列了它差在哪（无组头、无每组计数、无折叠、字母序而非节奏序），但它能读。duly#13上"showing who assigned each"整条交付不了。record:related_listcannot bind to a multi-value relationship field —RelatedListbuilds its parent filter as bare equality, which the driver refuses with 400 INVALID_FILTER #7299 是互锁的 —— 卡片指出另一条路（在duly_assignment上按多值assignees建 related list）被record:related_listcannot bind to a multi-value relationship field —RelatedListbuilds its parent filter as bare equality, which the driver refuses with 400 INVALID_FILTER #7299 挡死。record:related_listcannot bind to a multi-value relationship field —RelatedListbuilds its parent filter as bare equality, which the driver refuses with 400 INVALID_FILTER #7299 是 p2 且不 blocked，先修它就能给这个需求开出一条路；所以第 2 条的紧迫性可以合法地挂在record:related_listcannot bind to a multi-value relationship field —RelatedListbuilds its parent filter as bare equality, which the driver refuses with 400 INVALID_FILTER #7299 后面，这也是本卡不上 p2 的具体理由，而不是笼统的"不急"。⛔ 定型：两条都是 Feature，都踩 manual floor
新增
groupBy、新增点号列语法，都加宽公共可授权面；⊕ 键落在 spec 的组件 props ⇒ 协议变更。⛔ 分诊席不裁决、不派单。Restart-when（可执行探针）：与 #7300 同法，⛔ 判据是装得上而非上游合并 ——
两半不是同一份工作，卡片的合并理由是"在同一个组件、同一个页面上撞到的"，是位置上的而非修法上的：
groupBygrouping块已实现（含嵌套层级与逐层折叠），让 related list 收同一个块②的风险面也大得多（一跳的展开很容易变成 N+1 取数）。建议
domain:ui席在动手时拆成两张，①先做；⛔ 拆不拆由执行席定，本席不代拆 —— 因为两者的上游键很可能在同一次 spec 裁决里一起谈，过早拆卡会把那次裁决割成两半。给执行席的两条注意
grouping块，⛔ 不要新造一套 group 语法 —— 卡片说的"mostly plumbing"成立的前提正是复用同一个块；另造一套会让同一个概念在本仓有两种拼写，是 finding(types):KanbanCard/KanbanColumnare declared four times in this tree and the published copies disagree (cardsvsitems,badgesvslabels) #6155 那类缺陷的制造方式。Generated by Claude Code
objectstack-fleet commentedon Sep 24, 2026
分诊 — 维护者同意分诊建议：暂不做 · 按 not planned 关闭
分诊席 #6015，2026-09-24T18:06Z。
维护者裁决（原文）
分诊席今天把本卡作为待决事项④提给维护者：
record:related_list要不要支持groupBy，列能不能跨 lookup（例如assignment.assigner）？维护者答复原文：
④ 在「其他」里 ⇒ 按建议关闭。
关闭后的现状（照实记录）
columns首位、sort首位，同组的行会排在一起。没有组头、组计数和折叠。record:related_listcannot bind to a multi-value relationship field —RelatedListbuilds its parent filter as bare equality, which the driver refuses with 400 INVALID_FILTER #7299 已于 09-10 由 PR fix(plugin-detail): compile the related-list parent filter to match the relationship field arity (objectui#7299) #8886 修复（closed completed）：关联列表现在会按关系字段是单值还是多值来生成父过滤条件。所以「在duly_assignment上按多值assignees建关联列表、直接显示assigner列」现在可以写。什么情况下重开
出现第二个项目（duly 之外）提出同样的需求时重开。重开时附上那个项目的卡号。
Generated by Claude Code