Uh oh!
There was an error while loading. Please reload this page.
docs(spec): SystemFieldName says which columns are actually injected - #4430
Merged
Conversation
The table documented `tenant_id` as "Tenant isolation key" while the column the registry actually provisions is `organization_id` — which had no constant at all, alongside the equally-missing `created_by` / `updated_by`. Two of the seven entries (`user_id`, `deleted_at`) are not injected either, with nothing saying so. Consumers hand-copying a system-field list read this as the injection set and drifted accordingly: cloud#982 found three copies carrying `tenant_id`, `org_id` and `space` between them, none of which any injection site produces, and cloud#979 was one of those copies claiming a business field named `owner` so every seeded row shipped it blank. Additive only — no entry removed, no value changed: - add ORGANIZATION_ID, CREATED_BY, UPDATED_BY, the three injected columns the table was missing; - record per entry whether open-core injects it, so the legacy (`tenant_id`) and authored (`user_id`) names cannot be mistaken for provisioned ones; - state in the module doc that this is a NAME registry, not the injected set — `applySystemFields` decides that per object from `ownership` / `tenancy` / `systemFields`, so the same name is a system column on one object and business data on the next. A consumer asking "is this field system-managed on THIS object" branches on `Field.system`, which is already published for exactly that and which the doc now points at. `@objectstack/lint`'s SYSTEM_FIELDS is unaffected in content: it unions this table with FIELD_GROUP_SYSTEM_FIELDS, which already carried all three added names. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YRXTo7QC2A6EXXxJ5GKwsS
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 107 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YRXTo7QC2A6EXXxJ5GKwsS
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
SystemFieldName自称是 system fields 的 canonical 协议级名字表，但它既不是注入集，也不是「所有系统字段」集，而且对最关键的一项记反了：TENANT_IDapplySystemFieldsprovisions 的租户列是organization_id（lookup →sys_organization）。objectql plugin 只在对象自己声明了tenant_id时才 stamp，且填进去的值就是session.organizationId。这个仓自己的system-managed-fields-conformance.test.ts已经把它归类为 "legacy/enterprise tenant key (not injected by open-core)"ORGANIZATION_IDCREATED_BY/UPDATED_BYAUDIT_PROVENANCE_FIELDS的一半），表里没有USER_IDDELETED_ATapplySystemFields不注入；没写后果（已实测）
下游消费方把这张表当注入集手抄，然后各自漂移。cloud#982 在 cloud 一个包里查出三份手抄清单，分别带着
tenant_id、org_id、space—— 三个拼写没有任何注入点会产生。其中一份的漂移已经发作成用户可见故障（cloud#979）：清单里的owner让一个业务字段被当成系统列，种子生成器双重跳过它，每一行种子数据的「负责人」列都是空的。根因是这张表混装了三类东西（真注入 / 遗留别名 / 声明字段）却只给了一个名字，且缺了三个真注入列。
改动
纯增量 —— 不删任何条目、不改任何取值。
ORGANIZATION_ID/CREATED_BY/UPDATED_BY三个缺失的注入列常量；tenant_id）和声明（user_id）拼写不再可能被误当成 provisioned 列；applySystemFields按对象从ownership/tenancy/systemFields算出来的，所以同一个名字在 A 对象上是系统列、在 B 对象上是业务字段。要回答「这个字段在这个对象上是不是系统列」，应该 branch 在Field.system上 —— 那个标志本来就是为这件事发布的（field.zod.ts的 describe 原文就是这么说的），doc 现在指过去；兼容性
@objectstack/lint的SYSTEM_FIELDS内容不变：它是本表与FIELD_GROUP_SYSTEM_FIELDS的并集，而后者已经含这三个新增名字。其 "contains nothing BEYOND the two spec declarations" 断言照过。SystemFieldName.X引用零影响。验证
相关
Generated by Claude Code