From 109b96ba5ac6724e4d6153975065921abd753b69 Mon Sep 17 00:00:00 2001 From: delchev Date: Sat, 12 Sep 2026 08:42:42 +0300 Subject: [PATCH] docs(intent): personalReadOnly is declarable on a composition edge too (#7340) The key closed a whole personal surface or nothing, and a composition child cannot carry `personal:` at all, so a header the owner authors whose lines an engine writes had no expressible shape - the child was writable exactly when its parent was. On the composition relation it closes only the child's inherited surface: the child's MyController answers 403 and the parent's my/document page drops the items Add, the row actions and that child panel's Add, while the header keeps Save and Delete. Co-Authored-By: Claude Opus 5 --- docs/help/intent/dsl-reference.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/docs/help/intent/dsl-reference.md b/docs/help/intent/dsl-reference.md index a067e64e1..2ceba9bcb 100644 --- a/docs/help/intent/dsl-reference.md +++ b/docs/help/intent/dsl-reference.md @@ -1057,9 +1057,17 @@ on the personal shell; `partner: true` the mirror `PartnerController` on (`/services/web/partner/`, gated by the Customer / Supplier / Partner IdP roles). A `sensitive: true` field is stripped from those scoped responses and ignored on their writes (enforced server-side, not merely hidden). The regular controller is unaffected; an entity may carry both. -`personalReadOnly: true` (with `personal: true`) makes the personal surface see-only - the scoped -writes are refused and the pages render no new/edit/delete - for records the owner may see but -never author (a balance, a payslip); composition children inherit it through the parent. +`personalReadOnly: true` makes a personal surface see-only - the scoped writes are refused and the +pages render no new/edit/delete. Alongside `personal: true` it closes the declaring entity's own +surface, for records the owner may see but never author (a balance, a payslip). On a **composition +relation** it closes only that child's inherited surface while the parent stays writable - the scope +still comes from the parent, the writes do not - which is the shape of a header the owner authors +whose lines a generator writes (a leave request whose day rows the approval flow charges against an +entitlement): the child's `MyController` answers 403 and the parent's my/document page renders +no Add on that items panel, no row actions and no Add on that child panel, while the header keeps its +Save and Delete. The key is refused where it would be carried nowhere - on a relation that is neither +`personal: true` nor a composition, on a second composition of the same entity, or on a child whose +master has no personal surface to inherit. **Act as (delegated entry).** At runtime an ADMINISTRATOR can arm an *acting identity* for their session (`/services/core/actas`; the shells offer it as "Enter data as..." / "Act as...") and work