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
Activity
- addedenhancementNew feature or requestNew feature or requestdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatobjectui ui stream: fix lands on the published library or apps — objectui execution seat
on 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的完整已声明键,逐个读出来(不是抽样):objectName · relationshipField · columns · sort · limit · filter · title · showViewAll · actions · add · ariagroupBy不在其中 —— 在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."- 第 1 条有可接受的降级:
frequency放columns首位 +sort首位,各节奏成为连续块。卡片诚实地列了它差在哪(无组头、无每组计数、无折叠、字母序而非节奏序),但它能读。 - 第 2 条的代价更实:
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 同法,⛔ 判据是装得上而非上游合并 ——
pnpm add -D @objectstack/spec@latest >/dev/null 2>&1 \ && node -e "const s=require('@objectstack/spec/ui');const k=Object.keys(s.RecordRelatedListPropsSchema?.shape??{});console.log(k.join(','));process.exit(k.includes('groupBy')?0:1)"
⚠️ 这张卡该拆,但本席不代拆两半不是同一份工作,卡片的合并理由是"在同一个组件、同一个页面上撞到的",是位置上的而非修法上的:
工作性质 已有可复用机器 ① groupBy主要是接线 —— grid 的 grouping块已实现(含嵌套层级与逐层折叠),让 related list 收同一个块有,卡片指名 ② 点号列跨 lookup 新的解析逻辑 —— 要在取数与渲染两侧都展开一跳 只有 label 批量解析可借,路径展开是新的 ②的风险面也大得多(一跳的展开很容易变成 N+1 取数)。建议
domain:ui席在动手时拆成两张,①先做;⛔ 拆不拆由执行席定,本席不代拆 —— 因为两者的上游键很可能在同一次 spec 裁决里一起谈,过早拆卡会把那次裁决割成两半。给执行席的两条注意
- ①若接 grid 的
grouping块,⛔ 不要新造一套 group 语法 —— 卡片说的"mostly plumbing"成立的前提正是复用同一个块;另造一套会让同一个概念在本仓有两种拼写,是 finding(types):KanbanCard/KanbanColumnare declared four times in this tree and the published copies disagree (cardsvsitems,badgesvslabels) #6155 那类缺陷的制造方式。 - ②卡片自己划了边界并且是对的:"expands the lookup one level would cover most of what related lists need; deeper paths can stay refused"。⛔ 不要顺手做任意深度 —— 那是另一个数量级的取数问题,且没有实测需求支撑。
Generated by Claude Code
- 第 1 条有可接受的降级:
objectstack-fleet commented
on Sep 24, 2026 ContributorMore actions分诊 — 维护者同意分诊建议:暂不做 · 按 not planned 关闭
分诊席 #6015,2026-09-24T18:06Z。
维护者裁决(原文)
分诊席今天把本卡作为待决事项④提给维护者:
- 问题:
record:related_list要不要支持groupBy,列能不能跨 lookup(例如assignment.assigner)? - 本席的建议:暂不做,按 not planned 关闭,重开条件是「有第二个项目提出同样的需求」。理由是本卡自己也写了「nothing renders wrong, the page just cannot say the thing」。
维护者答复原文:
「需要我决定的 6 件事: 6947 7300 不做;其他同意」
④ 在「其他」里 ⇒ 按建议关闭。
关闭后的现状(照实记录)
- 第 1 条(分组):有可接受的降级。把分组字段放在
columns首位、sort首位,同组的行会排在一起。没有组头、组计数和折叠。 - 第 2 条(跨 lookup 的列):另一条路已经通了。
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
- 问题:
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
RecordRelatedListPropsdeclarescolumns,sort,filter,limit. There is nogroupBy, andRelatedListdraws its own table rather than a list view, so the grid'sgroupingblock (which does support nested levels with per-level collapse, and which this same app uses on aduly_dutylist 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
frequencyfirst incolumnsand first insort, 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
groupingalready 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
RelatedListresolves 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 isduly_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_assignmentitself, bound on its multi-valueassigneesfield — 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
https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p