proposal: a composition child may be read-only on a scoped surface independently of its parent - #74
Open
delchev wants to merge 1 commit into
Open
proposal: a composition child may be read-only on a scoped surface independently of its parent#74delchev wants to merge 1 commit into
delchev wants to merge 1 commit into
Conversation
…dependently of its parent `personalReadOnly` is declared alongside `personal: true`, and a composition child may not carry `personal:` at all - it inherits the owner's scope through its parent. So a child's scoped surface is writable exactly when its parent's is, which is the wrong coupling whenever a person authors a header whose lines a generator writes: a leave request is filed by the employee, its day rows are written only by the approval flow, and each one charges an entitlement - so the generated scoped controller accepts a create from the owner's own draft against any entitlement in the tenant, a colleague's account included. Nothing else expresses it. `personalReadOnly` on the parent closes the header the person must author; `sensitive:` hides a value and still takes the write; an immutability rule keyed on the parent's final statuses reaches the child but a DRAFT parent is mutable by definition - the window this lives in. The key is allowed on the child's composition relation - the edge the scope actually travels - and refused wherever it would be carried nowhere, since a dropped access declaration reads as a grant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Proposal
0018-child-scoped-read-only.md.personalReadOnlyis declared alongsidepersonal: true, and a composition child may not carrypersonal:at all - it inherits the owner's scope through its parent. So a child's scoped surface is writable exactly when its parent's is, and nothing can say otherwise.That is the wrong coupling whenever a person authors a header whose lines a generator writes. A leave request is filed by the employee, so its scoped surface must be writable; its day rows are written only by the approval flow, and each one charges an entitlement - so the generated scoped controller accepts a create from the owner's own draft against any entitlement in the tenant, a colleague's account included, and the scoped page offers it as an Add button.
Nothing else expresses it:
personalReadOnlyon the parent closes the header the person must author,sensitive: truehides values on read and still accepts the write, and an immutability rule keyed on the parent's final statuses does reach the child but a DRAFT parent is mutable by definition - which is exactly the window this lives in.The proposal allows the key on the child's composition relation, reading as the scope still comes from the parent; the writes do not, and refuses it wherever it would be carried nowhere (a non-composition non-personal relation, a second composition, a master with no scoped surface to inherit) - a dropped access declaration reads as a grant.
Proven out by eclipse-dirigible/dirigible#7354. Spec text for the next version document is carried in the proposal's Specification text section.
🤖 Generated with Claude Code