实施 #4616(通知孤儿 schema 移除)时的范围外发现,按 Prime Directive #10 立案,不在 #4616 PR 内修(跨仓,且属 objectui 的 bug)。
现象
objectui@785b8a5packages/app-shell/src/views/metadata-admin/clientValidation.ts:89:
email_template: async()=>(awaitimport('@objectstack/spec/system')).EmailTemplateSchemaasunknownasZodLikeSchema,Studio 的 metadata-admin 客户端草稿校验,把 email_template 这个 kind 注册到了 EmailTemplateSchema。但该 kind 的规范 schema 是 EmailTemplateDefinitionSchema —— BUILTIN_METADATA_TYPE_SCHEMAS(packages/spec/src/kernel/metadata-type-schemas.ts)、runtime metadata protocol、plugin-email 的物化桥都解析这一个。
两者形状不相交:
| EmailTemplateSchema(被移除的遗留形状) | EmailTemplateDefinitionSchema(规范) |
|---|
| 主键 | id(必填) | name + locale |
| 正文 | body + bodyType | bodyHtml / bodyText |
| 其他 | attachments | label / category / active / fromOverride / replyTo |
| 严格性 | 非 strict(未知键静默剥离) | strictObject |
结果:一份合法的 email_template 草稿在 Studio 里被报 id 缺失、body 缺失;而它真正的键(name/label/bodyHtml/…)因为非 strict 被静默剥离,不报错也不生效。
这正是 spec 7.1.0 在框架侧修过的同一个缺陷
spec 7.1.0 changelog 原文:email_template 曾有两个竞争 Zod schema(Prime Directive #8 违规),TYPE_TO_SCHEMA 与 BUILTIN_METADATA_TYPE_SCHEMAS 注册了遗留那个,"which is why all the new fields (name, label, category, locale, bodyHtml, bodyText, …) were reported as 'declared in form layout but missing from schema'"。框架侧当时改指到了 EmailTemplateDefinitionSchema,objectui 侧从未跟进。
混淆源头已在 #4616 一并修正:kernel/metadata-plugin.zod.ts:116 原注释写的是 // Outbound email templates (EmailTemplateSchema),指错了声明。
修复
clientValidation.ts:89 改为:
email_template: async()=>(awaitimport('@objectstack/spec/system')).EmailTemplateDefinitionSchemaasunknownasZodLikeSchema,同文件 permission 那条已有的注释("use PermissionSetSchema from /security, NOT PluginPermissionSchema from /kernel … See packages/spec/src/kernel/metadata-type-schemas.ts for the canonical mapping")就是这里该照抄的先例 —— 建议同样留一行注释指向规范映射表。
时序
#4616 已从 @objectstack/spec@v17 移除 EmailTemplateSchema,所以在 objectui 升到 v17 的那一刻,上面这行会变成编译错误(命名空间上不存在该属性),而不是继续静默错校验 —— 这是刻意的:让错误落在唯一需要改的那一行上。objectui 升 v17 前修掉即可,不需要等 v17 发布。
注意 EmailTemplateDefinitionSchema 是 strictObject,接上之后未知键会响亮拒绝而不是剥离,所以修复本身也可能暴露既有草稿里的脏键 —— 这是期望行为(contract-first),但值得在 PR 里实跑一遍 Studio 的 email_template 编辑页确认。
关联:#4616(移除 PR)、spec 7.1.0(框架侧的同一修复)、Prime Directive #8 / #12。
实施 #4616(通知孤儿 schema 移除)时的范围外发现,按 Prime Directive #10 立案,不在 #4616 PR 内修(跨仓,且属 objectui 的 bug)。
现象
objectui@785b8a5packages/app-shell/src/views/metadata-admin/clientValidation.ts:89:Studio 的 metadata-admin 客户端草稿校验,把
email_template这个 kind 注册到了EmailTemplateSchema。但该 kind 的规范 schema 是EmailTemplateDefinitionSchema——BUILTIN_METADATA_TYPE_SCHEMAS(packages/spec/src/kernel/metadata-type-schemas.ts)、runtime metadata protocol、plugin-email的物化桥都解析这一个。两者形状不相交:
EmailTemplateSchema(被移除的遗留形状)EmailTemplateDefinitionSchema(规范)id(必填)name+localebody+bodyTypebodyHtml/bodyTextattachmentslabel/category/active/fromOverride/replyTostrictObject结果:一份合法的 email_template 草稿在 Studio 里被报
id缺失、body缺失;而它真正的键(name/label/bodyHtml/…)因为非 strict 被静默剥离,不报错也不生效。这正是 spec 7.1.0 在框架侧修过的同一个缺陷
spec 7.1.0 changelog 原文:
email_template曾有两个竞争 Zod schema(Prime Directive #8 违规),TYPE_TO_SCHEMA与BUILTIN_METADATA_TYPE_SCHEMAS注册了遗留那个,"which is why all the new fields (name,label,category,locale,bodyHtml,bodyText, …) were reported as 'declared in form layout but missing from schema'"。框架侧当时改指到了EmailTemplateDefinitionSchema,objectui 侧从未跟进。混淆源头已在 #4616 一并修正:
kernel/metadata-plugin.zod.ts:116原注释写的是// Outbound email templates (EmailTemplateSchema),指错了声明。修复
clientValidation.ts:89改为:同文件
permission那条已有的注释("use PermissionSetSchema from /security, NOT PluginPermissionSchema from /kernel … See packages/spec/src/kernel/metadata-type-schemas.ts for the canonical mapping")就是这里该照抄的先例 —— 建议同样留一行注释指向规范映射表。时序
#4616 已从
@objectstack/spec@v17移除EmailTemplateSchema,所以在 objectui 升到 v17 的那一刻,上面这行会变成编译错误(命名空间上不存在该属性),而不是继续静默错校验 —— 这是刻意的:让错误落在唯一需要改的那一行上。objectui 升 v17 前修掉即可,不需要等 v17 发布。注意
EmailTemplateDefinitionSchema是strictObject,接上之后未知键会响亮拒绝而不是剥离,所以修复本身也可能暴露既有草稿里的脏键 —— 这是期望行为(contract-first),但值得在 PR 里实跑一遍 Studio 的 email_template 编辑页确认。关联:#4616(移除 PR)、spec 7.1.0(框架侧的同一修复)、Prime Directive #8 / #12。