Repository navigation
automation「电子邮件模板」节的合并字段示例 {{Opportunity.Name}} / {{Account.Owner.Email}} 用的是本仓不存在的对象/字段拼写 #863
Description
Activity
🔒 认领(/pm-dispatch R27)— session
session_01VHrPAGEgFDoHjphqYG4BMa,分支claude/issue-863-merge-field-spelling。文件面:
content/docs/administration/automation{,.zh-Hans,.zh-Hant}.mdx合并字段 bullet 一行 ×3——本页经 #854/#864/#870/#879/#906 多轮改动,行号(en :122 / zh :120)fresh main 上重定位。裁定:
- 基线已切 17.0.0-rc.3(PR chore(deps): 升级 @objectstack/* 17.0.0-rc.2 → 17.0.0-rc.3(零后果修复),并实测四条在案上游镜像 #910)。rc.3 对 email-template spec 无变更,premise 预计成立,仍须复核
EmailTemplateDefinitionSchema注释与{{path.to.value}}语法主张。 - 采用「不依赖载荷形状」写法(issue 给出的两个选项中的前者):示例换成本仓真实拼写(
crm_opportunity/name/owner_id等 snake_case),并如实写明占位符路径取决于每次发送传入的data载荷形状、由调用方决定、本仓当前没有调用方——不虚构{{record.name}}之类未经实测的前缀形状,不向平台侧开确认单(收益不配成本)。 - 同页其余部分(含 docs(automation): retire the workflow-rules section in all three locales (#833) #854/docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870/docs(automation,opportunities): 补回 zh 两页缺的预测分工段，并按语言包对齐 best_case / closed_amount 词 (#836, #845) #879 已落地内容)不得动;convert 词汇沿 docs(i18n): spell the lead convert verb 转化 on every Chinese page (#844) #906 口径。
Generated by Claude Code
- 基线已切 17.0.0-rc.3(PR chore(deps): 升级 @objectstack/* 17.0.0-rc.2 → 17.0.0-rc.3(零后果修复),并实测四条在案上游镜像 #910)。rc.3 对 email-template spec 无变更,premise 预计成立,仍须复核
✅ 验收通过 —— PR #911 已转 ready 并挂 auto-merge(CI 8/8 全绿实核,head 206d13b,4 文件与声明一致)。
验收要点:
- premise rc.3 复核成立:spec 头注释与
EmailTemplateDefinitionVariableSchema.namedescribe 逐字仍在——占位符语法没错,错的只是拼写;本仓真名(crm_opportunity/crm_account/crm_contact、name/owner_id/email)逐个到源码行号核实。 - 裁定执行到位:采用不依赖载荷形状的写法——示例用真名、点名不是 Salesforce 式、如实写明路径根部由发送方
data载荷决定且本仓无sendTemplate()调用方(src/content/config 零命中,与 automation 三语的「内置模板涵盖潜在客户路由、商机赢单、案例确认、合同激活、续约提醒」—— 本仓一个邮件模板都没有 #834 产物结论互证),把作者指向模板自身variables列表;未虚构任何前缀形状。 - 面控严格:三语各一处 bullet(fresh main 重定位到三语同 :122,修正了派单里 zh :120 的近似),同页其余一行未动,与并行 「工作流规则」清扫后仍有 bare
workflows残留族：faq / performance-and-limits 的「重新评估 5 次后停止」是 PR #854 已判虚构那条说法的未清扫副本，quotes:141 指向不存在的配置面 #899 零交叠。 - 三语术语沿既有口径(载荷/酬載对齐 integrations 页);守卫盲区(文档正文无断言测试)如实报 predicted GREEN。
Generated by Claude Code
- premise rc.3 复核成立:spec 头注释与
- added a commit that references this issue
on Aug 10, 2026
来源：#834 实施过程中的顺带发现（同一节的另一条 bullet，不在 #834 的改动面内，未在该 PR 中修改）。基线
origin/main= eb4a7e1。事实
content/docs/administration/automation.mdx:122（zh-Hans:120、zh-Hant:120）：占位符语法本身是对的。
EmailTemplateDefinitionSchema（node_modules/@objectstack/spec/src/system/email-template.zod.ts，spec 17.0.0-rc.2）的头注释写明：subject / body 承载{{path.to.value}}占位符，按每次发送的data载荷渲染；EmailTemplateDefinitionVariableSchema.name的描述是Variable name as referenced in placeholders (snake_case or dotted path)。不对的是路径的拼写。 本仓的对象是
crm_opportunity/crm_account，字段是name/owner_id/email。Opportunity、Name、Account.Owner.Email这几段在本仓不是任何对象或字段的拼写，是 Salesforce 式 PascalCase 的借用示例。AGENTS.md 对此有硬约束：同页其余地方（flow 表、顺序小节）引用字段时用的都是真实拼写（
end_date、expiration_date、owner_id），只有这一条 bullet 例外。影响与证据边界
管理员在 设置 → 电子邮件模板 里照抄这两个示例写占位符，渲染时对不上任何值。
未实测的部分，如实说明：本仓不 author 任何邮件模板，也没有调用
IEmailService.sendTemplate()的代码路径（#834 已复核：dist/objectstack.json顶层无邮件模板集合，产物内email_template零命中），因此无法在本仓端到端测出渲染结果。这里只证明了「示例里的拼写在本仓不存在」，没有证明平台侧对这两个字符串会怎么处理。修复面（未做，留给 triage）
把示例换成本仓真实拼写即可让这一条自洽。但换成什么形状取决于一个本仓测不出的问题：模板的
data载荷究竟以什么形状传入（record 展平成{{name}}，还是带前缀的{{record.name}}/{{crm_opportunity.name}}）。spec 只说「按每次发送的data载荷渲染」，载荷形状由调用方决定，而本仓没有调用方。所以这一条要么写成不依赖载荷形状的说法，要么先向平台侧确认一次再定示例文本。Refs #834 #800