Repository navigation
EventAttendeeViews.list 在事件详情页的与会者面板上不被消费——关联列表读的是 highlightFields;该 grid 只在无导航入口的对象列表 URL 上渲染 #964
Description
Activity
定级（首触）→ 关闭 not planned。实质的那一半已由 PR #957 落地，剩下的是零拉力的策展选择。
按本席常设授权定级。
finding同笔摘除。前提对
origin/main@6ed7b8d重测src/objects/event_attendee.object.ts:146 highlightFields: ['crm_event', 'attendee_type', 'response', 'is_organizer'], src/views/event_attendee.view.ts — list 仍在（7 列），form 仍在与卡片一致：关联列表面板渲染的是
highlightFields去掉作用域字段后的三列，EventAttendeeViews.list那 7 列不参与。为什么关 —— 三条，逐条对应卡片自己的证据
1. 真正的缺陷已经修了。 卡片记的是「一块声明了、那条路径上没人读的表面」，但它同时记了：这块表面之所以危险，是因为一条说反了的文件头注释曾让人把它当成关联列表的配置项。PR #957 已经把机制写进
src/views/event_attendee.view.ts的文件头，并在test/view-references.test.ts钉住了真正承重的highlightFields。制造误读的那个东西没有了。2. 它不是 declared-≠-enforced，所以不进 enforce-or-remove 通道。 这一条要说清楚，因为形状很像：
list并没有「声明了但运行时不兑现」——它是被消费的，只是消费它的是对象列表 URL，而不是关联列表面板。那个 URL 今天没有导航入口，但页面确实会渲染。⇒ 删掉它是删掉一个能用（只是难到达）的表面，不是清理惰性声明。这与本仓正在做的 ADR-0049 清扫不同判。3. 剩下的三个选项没有一个有拉力。 卡片自己给的 A / B / C：
- A 保留现状：成本为零，而它担心的代价（下一位作者误读）已由 PR fix(views): write the measured related-list mechanism to source (#944) #957 的注释 + 守卫消掉。
- B 声明
relatedListColumns：卡片自己写明「属能力扩张，需要真实业务拉力」。没有拉力 —— 没有用户报告与会者面板缺列。轴④。 - C 退休
list：要连带清四语_views标签，而收益是删掉一个仍会渲染的表面。净负。
⇒ 落在 A，而 A 的内容就是「什么都不做」。一张内容为「什么都不做」的卡不该占着待办位。按「暂时不准备开发的应该直接关闭」（维护者 2026-08-16）关 not planned。卡即记录，重开免费，维护者可否决。
什么情况下重开
- 与会者关联列表面板真的缺列被用户或 dogfood 撞见 ⇒ 那时选项 B 有了拉力，重开本卡（
relatedListColumns可超过highlightFields的 6 列上限，是那时的正解）。 crm_event_attendee获得导航入口 ⇒ 那份 grid 从「难到达」变成「常用」，它的列策展重新值得看。
不混：#733（商机详情页 Products 侧栏显示行项目原始记录 ID）在同一片渲染面上但机制不同（
nameField而非列来源），⛔ 不因本卡关闭而受影响。
Generated by Claude Code
发现自 #944 / PR #957 的测量。观察级留档:今天没有用户因此看到错误的东西(面板列是策展过的,只是不是这份 view 给的),但这是一块「声明了、那条路径上没人读」的元数据表面,值得一次显式决定而不是继续默认存在。
基线
origin/main=b7791caf(平台 17.0.0-rc.3)。事实(对 17.0.0-rc.3 的 Console 产物静态测量,四处)
RecordDetailView的关联列表派生、RelatedList的列回退链、MetadataProvider的 view→object 合并、form 渲染器 create 模式的字段过滤:relatedListColumns(本仓一处都没写) → 子对象highlightFields去掉该面板的作用域字段(上限 6 列,丢弃在所有已取行上都为空的列) → 字段表启发式。全程不读子对象的 list view。attendee_type/response/is_organizer(来自crm_event_attendee.highlightFields去掉crm_event),不是EventAttendeeViews.list那 7 列(attendee_type/crm_contact/crm_lead/sys_user/external_name/response/is_organizer),rowColor与sort同理不参与。crm_event_attendee在src/apps/crm.app.ts里没有导航项(view 文件自己也这么说),所以这份 grid 只在直接访问该对象的列表 URL 时才渲染。form是活的:Console 把 view bundle 的form合并到它持有的对象定义上,关联列表的新建/行编辑抽屉渲染其sections。所以本单只针对list,不针对form。PR #957 已把上述机制写进
src/views/event_attendee.view.ts的文件头注释(它原先的说法正好相反),并在test/view-references.test.ts钉住了真正承重的highlightFields。本单留的是那份 grid 自身的去留决定。处置面(需要决定,本单不预判)
crm_event_attendee.crm_event上声明relatedListColumns(可超过highlightFields的 6 列上限、可与详情高亮条不同),grid 保留或退休。属能力扩张,需要真实业务拉力。list,只留form。 连带四语_views标签一并清理(test/i18n-references.test.ts的孤儿检查会盯住这一步)。相关
crm_opportunity_line_item/crm_quote_line_item未声明nameField)是同一片渲染面上的另一处,机制不同(nameField 而非列来源),不混。crm_campaign_member根本没有 view 元数据，但event_attendee.view.ts:10的注释以「campaign_member 有」为立论前提——按该注释自己的推理，营销活动详情页的成员关联列表在裸退化 #944 / PR fix(views): write the measured related-list mechanism to source (#944) #957 是本单的来源。