Repository navigation
v0.6 wrap-up: read-only snapshot fields for lookups the portal cannot read #95
Description
Found in the v0.6 portal exit test (local). Part of #75.
Problem
On records a portal user may read, some lookup fields point at objects the portal cannot read, so the portal shows the raw id instead of a name:
- admission application → categories (
srm_category) - SCAR → material (
srm_material) and responsible SQE (sys_user, portal can only read itself)
Opening read access is not an option: srm_material and srm_category have no supplier field, so a membership-key RLS cannot limit rows to the supplier's own, and a full read leaks other suppliers' catalogue. The platform's "Restricted record" rendering (objectui#13335) does not leak, but the supplier still cannot tell which category or material is meant.
Ruling (director thread, 2026-11-02): option B
- General rule in 04 §4.2: when a portal page shows a lookup whose target the portal cannot read, the referencing object gets a read-only text snapshot field written by a flow (
category_names,material_name,sqe_name, …). FLS read-only for every position; the portal reads only the snapshot. Written on create and when the lookup changes (record_change flow); renaming the referenced record is not written back, lag accepted. - Scope is every portal-reachable object, not just these three: add to the U2 static metadata test that every lookup on a portal-reachable object either targets an object the portal can read or has a snapshot field (contracts, performance reviews, appeals, … all checked).
- Merge before the v0.7 gate-2 field freeze (snapshot fields are core fields; adding them after the freeze needs an ADR and migration).
- Platform side is a feature gap, not a defect: "show the name of a lookup target the viewer cannot read" goes into 07 §6.3 and an objectstack feature issue via the fleet relay. If the platform ships it, keep the snapshot fields.
Metadata
Metadata
Assignees
Labels
No labels
Activity
marchtian commentedon Nov 3, 2026
New ruling (director thread, 2026-11-03): use
referenceNameVisible, no snapshot fieldsObjectStack 18.3.0 ships the platform side of PF21 / objectstack#29171: a
lookuporuserfield can declarereferenceNameVisible: true, and every reader of the record gets the target's name + id on$expand(nothing else of the target, rendered as text without a link). Since no snapshot field has been built yet, the director ruled to use the declarative platform key instead of option B (ADR-0001 first; no new core fields or flows before the v0.7 freeze; names stay live). The earlier "keep the snapshots if the platform ships it" applied only to snapshots that already existed, so it lapses.Conditions:
categories, SCARmaterial, SCARsqe; plus any other lookup on a portal-reachable object that the U2 static test finds). Off by default. Never on a lookup that points at another supplier's records (asupplierfield pointing at the supplier's own record, e.g. in v0.7 sourcing invitations and quotes, is the exception). This goes into the isolation red-line checklist.referenceNameVisible: trueand is on the whitelist", and asserts that no lookup outside the whitelist sets the key.$expandof a lookup with the key gets only name + id, no other target fields, and cannot read the target record by id.04 §4.2: rewrite the snapshot rule as the whitelist rule above; keep one sentence that snapshot fields are the fallback when the platform cannot do it.
Generated by Claude Code
chore(core): upgrade to ObjectStack 18.3.0 and retire the fixed worka…