docs(data): describe the built-in value lock that actually exists - #360
Open
lovepixel-git wants to merge 1 commit into
Open
docs(data): describe the built-in value lock that actually exists#360lovepixel-git wants to merge 1 commit into
lovepixel-git wants to merge 1 commit into
Conversation
CoreBunch#303 removed `isBuiltInValueLocked` and `lockedBuiltInCellKey`, but the docs still describe them. Both symbols now have zero references anywhere in the codebase. The paragraph is not just naming dead functions, it states the opposite of current behavior. It says built-in row values are read-only on the structural system tables. They are editable on existing records, exactly as the guard's own header says. What survives is a narrower create-time rule: `protectedBuiltInCreateCellKey` rejects a create that supplies built-in cells for a structural system table, so those rows are born through their own authoring surfaces rather than the generic row endpoint. `posts` is exempt, and the server enforces it in `server/handlers/cms/data/tables.ts`. PageTreeCell and its test carried the same dead reference in comments, justifying the always-read-only button behavior by a predicate that no longer exists. The behavior is right and unchanged; the reasoning is now stated in terms of what a `pageTree` cell is (authored in the visual editor, never typed into a cell) rather than a deleted lock. Docs only, plus two comments. No behavior change.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What is stale
#303 removed
isBuiltInValueLockedandlockedBuiltInCellKey. Both now have zero references anywhere insrc/,server/ordocs/apart from the three sites this PR fixes.The problem is not only the dead names.
docs/features/data-workspace.mdcurrently states the opposite of what the code does:They are editable on existing records, which is what
systemTableGuard.ts's own header says:What actually survives is narrower and create-time only:
protectedBuiltInCreateCellKeyrejects a create that supplies built-in cells for a structural system table, so those rows are born through their own authoring surfaces rather than the generic row endpoint.postsis exempt viakind === 'postType', and the server enforces it atserver/handlers/cms/data/tables.ts:313. The docs paragraph now describes that.Two comments, same dead reference
PageTreeCell.tsxandPageTreeCell.test.tsxboth justified the always-enabled "Open editor" button by claimingisBuiltInValueLockedholds for every built-in field ofpages/components/layouts.The behavior is correct and unchanged. Only the reasoning was wrong, and it was wrong in a way that mattered:
readOnlyon that cell does not come from a built-in value lock at all. It is a grid-level prop, and apageTreecell is never editable inline because the tree is authored in the visual editor rather than typed into a cell. Both comments now say that instead.Scope
Docs plus two comments. No behavior change, so no new test.
bun run lintis clean and the 11 tests acrossPageTreeCell.test.tsxandsystemTableGuard.test.tspass.Happy to drop the comment edits and keep this to the doc line if you would rather review them separately.