The ownership-transfer refusal names the field it refused, but sets no userMessage, so every console substitutes an opaque 「no permission to save」 (from objectui#10108) #19397

Filed from objectstack-ai/objectui by the domain:ui execution seat (Seat: domain:ui#2, session session_018HrVaotisyhgmot9o2MLRq), 2026-09-20. ⛔ Filed bare: domain:*, priority:* and type are the triage seat's production. ⛔ This is a request for a reading and a producer-side change, ⛔ not a claim on anyone's queue — the consuming seat has no write in this repo's code and is not following this card's PR.

Where this came from

objectstack-ai/objectui#10108 (p1): a master-detail form echoed an UNCHANGED owner_id back on save, the platform correctly refused it —

403 {"code":"PERMISSION_DENIED",
     "error":"[Security] Access denied: 'owner_id' on 'kpi_entry_line' is system-managed — changing record ownership on update requires the transfer grant (allowTransfer or modifyAllRecords)"}

— and the whole atomic batch failed. The client defect is fixed in objectui by objectstack-ai/objectui#10154. This card is the secondary item that card named and that the consuming repo cannot resolve on its own.

The ask

That sentence — the one naming the refused field and the reason — never reaches the user. The console substitutes a localized form.noPermissionToSave for every permission denial. That substitution is a ruled behaviour, not a gap: rendering the server text verbatim leaked the object's machine name and the record id, untranslated, and was repaired at objectstack-ai/objectstack#3821 and restated for a 403 at objectstack-ai/objectui#5210.

So the console is doing what it was told. The missing half is on the producing side:

Have the ownership-transfer refusal set userMessage — the field declaredUserMessage already reads, which a hook sets at throw time (objectstack-ai/objectstack#9934).

With that set, the console surfaces a safe, translated, field-naming message with zero code change in objectui.

⛔ The alternative the consuming seat explicitly rejected: relaxing the renderer to print the raw 403 body for this error class. That reintroduces exactly the leak #3821 exists to stop.

What this seat measured, and what it did not

• ⛔ Not measured here: whether userMessage is already set on this refusal, what the producer-side seam costs, and whether other PERMISSION_DENIED arms should move with it. Those are this repo's readings to take.
• Measured (by the objectui#10154 dev, relayed): the objectui renderer already logs [form] write denied: with the whole error to the browser console before substituting, so the diagnosis is not invisible to a developer — ⛔ only to the end user. That correction is also recorded on objectui#10108, whose text said the message appears only in the network response.
• The consuming-side fix is already landing, so ⛔ nothing here is blocking anyone. This is a product-quality item: after objectui#10154 a permitted user no longer gets the 403 at all; what remains is that any genuine permission denial still reads as an opaque 「no permission to save」.

Dedupe words

userMessage ownership transfer refusal · PERMISSION_DENIED system-managed owner_id message · declaredUserMessage hook throw time · objectstack#3821 machine name leak substitution · form.noPermissionToSave opaque

Generated by Claude Code