Repository navigation
crm_campaign_member 根本没有 view 元数据，但 event_attendee.view.ts:10 的注释以「campaign_member 有」为立论前提——按该注释自己的推理，营销活动详情页的成员关联列表在裸退化 #944
Description
Activity
🔒 认领(/pm-dispatch R31)— session
session_01VHrPAGEgFDoHjphqYG4BMa,分支claude/issue-944-campaign-member-views。文件面:
src/views/(可能新增 campaign_member.view.ts + index.ts 导出)或仅src/views/event_attendee.view.ts:10注释——二选一由测量定,元数据单。裁定(measure-first):
- 先测:①campaign-members 文档三语向读者承诺了什么形态的成员列表;②event_attendee.view.ts 为自己 authored grid+form 的理由(其 :10 注释自述机制)是否同样适用于 campaign_member(字段面、autonumber 首字段问题、关联列表裸渲染);③dist 产物里 campaign_member 相关 view 声明现状。
- 默认修法 A:沿 event_attendee 模式补最小 CampaignMemberViews(grid+form),字段选择照抄其取舍逻辑(避开 autonumber 首字段、列出人读的字段),index.ts 导出;若测量发现「无 view」是刻意设计(如有注释/
#547类先例佐证),转修法 B:只修 event_attendee.view.ts:10 的失实注释,并把 A 的理由写成 finding 留档。取舍在 PR 说明。 ⚠️ 本单动 src/**:六道门全跑 + dist 产物结构核对(新增 view 出现在 objectstack.json);无浏览器实测条件,影响推断如实标注(沿 issue 正文姿势);不碰 @objectstack/* 版本、releases/、Campaign member lifecycle: support contacts, live metrics, and trim tracker fields that have no writer #597(成员生命周期 needs-user-decision)不预判。- changeset patch 级;若新增 view 的字段/标签涉 zh 翻译,语言包同步(沿 fix(i18n): 五处 zh-CN help 串按 B1 跟 label 收口 (#846) #859 先例)。
Generated by Claude Code
✅ 验收通过 —— PR #957 已合并(CI 9/9 全绿实核)。
验收要点:
- measure-first 裁定的教科书执行:premise partial 判得准——事实面成立(全仓无 view),影响面被 Console 产物逐句证伪(关联列表列走 relatedListColumns→highlightFields→启发式,不读 list view;快速新建先剔 autonumber)——「两者必有一错」而错的是注释,修法 B 转向有完整测量支撑。
- 不为修而修:认定修法 A「无可测业务拉力且新增无人渲染的表面」——这句判断本身就是本单价值;零元数据变更,产物与基线逐项一致。
- 守卫钉在真正承重处:新守卫钉 highlightFields(派生集合 = 有 required crm_ lookup 且无导航项的四对象),反向预判红实测红(2 failed 点名);注释改动无法直接钉住的边界如实标注。
越界发现处置:#961(文档承诺的 Members 选项卡/四视图/Add Members 流程不存在——「文档对齐产品」还是「产品对齐文档」两条处置面)→ 标 needs-user-decision 入决策箱(第 19 件),这是产品方向判断不由修复线代裁;#964(EventAttendeeViews.list 无消费面,三条处置面)→ finding 留池,dev 已正确标注。
Generated by Claude Code
- added a commit that references this issue
on Sep 9, 2026 - added a commit that references this issue
on Sep 25, 2026
发现自 #938 / PR #942 的实施过程（marketing/index《Where to find things》一节末句把读者指向「营销活动详情页」去看已加入的线索，核实这条路径时读到的）。
基线
origin/main=11f62429（平台 17.0.0-rc.3）。事实
src/views/event_attendee.view.ts:5-:16的文件头注释，把自己存在的理由建立在crm_campaign_member上：但
crm_campaign_member没有这些 view：ls src/views/ | grep -i campaign→ 只有campaign.view.ts（是crm_campaign的，不是成员的）。src/views/index.ts导出 15 个 view 模块，没有CampaignMemberViews。grep -rln "crm_campaign_member" src/ --include="*.view.ts"→ 只命中event_attendee.view.ts自己那句注释。也就是说，注释里作为「已成立的先例」被引用的那个对象，恰恰是反例。
影响（按注释自己的推理）
如果
event_attendee.view.ts对机制的描述是准确的——它是本仓对这条渲染路径唯一的成文说明——那么crm_campaign_member今天就正处在它描述的退化态：member_number（autonumber）当作首个可填字段呈现。我没有在浏览器里实测（本单按派发要求不起 dev server），所以影响一栏是从该注释的断言推导的，不是观测值。接手的人应先跑一次 dogfood 确认退化的具体形态，再决定补 view 还是改注释。
至少可以确定的是:两者必有一错——要么
crm_campaign_member缺 view 元数据，要么event_attendee.view.ts:10的注释在拿一个不存在的先例说事。与已有单的边界
crm_campaign_member的Basic Information字段组被highlightFields全部提升、导致该组在详情页永不渲染（lint field-group-shadowed，本次pnpm validate仍在报）。那是 object 上fieldGroups与highlightFields的冲突；本单是根本没有 view 文件，两者机制与修法都不同，可能需要一起收但不是同一处改动。needs-user-decision；本单是 UI 元数据缺失，不依赖那些产品决定。marketing/index的《Where to find things》(:74) 只列了 Campaigns，漏掉 Marketing 分组里真实存在的 Products（crm.app.ts:126） #938 / PR docs(marketing): name Products in the index page's "Where to find things" (#938) #942 无重叠：那单只改content/docs/marketing/index*.mdx的散文，src/零改动。建议的处置面
补
src/views/campaign_member.view.ts（grid + form，参照event_attendee.view.ts的形状），在src/views/index.ts导出，并按src/translations/{en,zh-CN,es-ES,ja-JP}.ts四语补 view label；或者，若判定关联列表的默认退化可接受，则改掉event_attendee.view.ts那句失实的注释。二选一，别两边都放着。Refs #715 #597 #938 #942