`EventAttendeeViews.list` 在事件详情页的与会者面板上不被消费——关联列表读的是 `highlightFields`;该 grid 只在无导航入口的对象列表 URL 上渲染

[yinlianghui]

发现自 #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 模式的字段过滤:

1. 详情页关联列表的列来源顺序:子对象 lookup 字段上的 relatedListColumns(本仓一处都没写) → 子对象 highlightFields 去掉该面板的作用域字段(上限 6 列,丢弃在所有已取行上都为空的列) → 字段表启发式。全程不读子对象的 list view。
2. 因此事件详情页的与会者面板渲染的是 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 同理不参与。
3. crm_event_attendee 在 src/apps/crm.app.ts 里没有导航项(view 文件自己也这么说),所以这份 grid 只在直接访问该对象的列表 URL 时才渲染。
4. 同一 bundle 的 form 是活的:Console 把 view bundle 的 form 合并到它持有的对象定义上,关联列表的新建/行编辑抽屉渲染其 sections。所以本单只针对 list,不针对 form。

PR #957 已把上述机制写进 src/views/event_attendee.view.ts 的文件头注释(它原先的说法正好相反),并在 test/view-references.test.ts 钉住了真正承重的 highlightFields。本单留的是那份 grid 自身的去留决定。

处置面(需要决定,本单不预判)

• A. 保留现状。 grid 作为「关于一位与会者该展示什么」的策展答案留在对象列表页,接受它不服务关联列表。成本为零,代价是这块表面继续容易被下一位作者当成关联列表的配置项(这正是被改掉的那条注释制造过的误读)。
• B. 把想要的列写到真正被读的键上。 在 crm_event_attendee.crm_event 上声明 relatedListColumns(可超过 highlightFields 的 6 列上限、可与详情高亮条不同),grid 保留或退休。属能力扩张,需要真实业务拉力。
• C. 退休 list,只留 form。 连带四语 _views 标签一并清理(test/i18n-references.test.ts 的孤儿检查会盯住这一步)。

相关

• [17.0-rc2验收] 商机详情页「Products」侧栏直接显示行项目原始记录 ID —— crm_opportunity_line_item / crm_quote_line_item 未声明 nameField #733(商机详情页 Products 侧栏显示行项目原始记录 ID,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 是本单的来源。