fix(uve): gate contentlet edit affordances on edit permission

[rjvelazco]

Spec-Kit PR 2 of 2 — implementation. Spec approved and merged in #37404.

⚠️ The spec was amended after approval and needs re-approval (commit 96a4669c51). Headless/SDK pages were an explicit non-goal; they are now in scope. Reasoning below under Amended scope.

Proposed Changes

Gates every UVE affordance that modifies a contentlet on the user's EDIT permission for that contentlet instance, and deliberately leaves structural page actions alone.

Path	Behavior when denied
Edit pencil (icon row + ⋯ menu)	disabled, permission tooltip
Quick Edit ⚡ (icon row + ⋯ menu)	disabled, permission tooltip
Quick Edit side panel (tab 0)	dedicated no-permission mode with a notice — no form, no save
Style editor button + side panel (tab 1)	disabled; the tab shows the permission notice instead of the style form
Inline edit — WYSIWYG	refused, toast explains why
Inline edit — Block Editor	refused, toast explains why
Delete / move / add	unchanged — still work

That last row is the point, not an omission: a user allowed into the page editor may change the page's composition — which contentlets it uses. Contentlet permission governs the contentlet itself, which is why style editing is gated: style properties describe how that contentlet presents itself, not how the page is assembled.

Both side-panel tabs refuse consistently. An earlier build gated the quick-edit tab but not the style tab, so switching tabs on a restricted contentlet surfaced an editable style form. Fixed in 13e2cd7d88.

Root cause

ContainerLoader.java:358 has stamped data-dot-can-edit on every contentlet wrapper in EDIT mode since 2018, from a WRITE-level check against the contentlet instance. A repo-wide search finds only two producers and no consumer anywhere — Java, Velocity or TypeScript. Every gate defaulted to "allowed".

This PR wires that existing value through readContentletDataset() into the editor payload and applies it at four guard points.

Three things worth a reviewer's attention

1. Fail open is deliberate. dataset['dotCanEdit'] !== 'false', never === 'true'. Headless/SDK-rendered pages never emit the attribute; failing closed would disable all five affordances on every headless page for every user, including admins. ADR-0019 (date-lockstep SDK versioning) requires the same graceful degradation. Pinned by tests in dom.spec.ts and controls in every suite.
2. $contentletEditData needed a fix to make the panel gateable. It swaps the DOM payload contentlet for the page-asset one to pick up a fresh inode after a save — and the permission exists only on the DOM payload. Without carrying it across, the panel had nothing to gate on.
3. The Block Editor is a genuinely separate event. Different DOM marker ([data-block-editor-content]), different transport (postMessage, not a DOM handler), different file. Gating only handleInlineEditing would have left block-editor fields fully editable.

This is not a security fix

ESContentletAPIImpl.checkin → checkPermission already requires PERMISSION_WRITE on the instance, and #36510 hardened the adjacent copy paths for #34215. This corrects a misleading affordance — the UI advertising actions the server refuses — not a write bypass. Severity stays Medium.

Checklist

• Tests — TDD throughout, Red confirmed before each implementation. sdk-uve 111 passed; portlets-edit-ema-portlet 1446 passed, 5 skipped. Commits alternate test(...) (Red) → fix(...) (Green).
• Translations — one new key, uve.contentlet.no.edit.permission, shared by all four surfaces so they read identically.
• Security Implications Contemplated — see above. Consumes a server-computed permission rather than inventing a client-side one; the refusal message exposes no permission internals.

Not done, on purpose

• Playwright e2e — explicit recorded decision. No limited-permission user fixture exists; building one (user, role, type/instance permission split, page) exceeds the fix. Worth its own ticket.
• Manual QA (quickstart.md §3) — needs a live environment with the permission split; not run here, handed to QA. The full scenario is written out.
• Legacy script-injection client — behind FEATURE_FLAG_UVE_LEGACY_SCRIPT_INJECTION, off by default.

Amended scope: headless / SDK pages are now covered

Originally scoped out on the assumption it meant a substantial Page API change. Two findings overturned that:

1. The permission was already being computed and discarded. PageRenderUtil:338 computes the per-contentlet WRITE permission for the Velocity $EDIT_CONTENT_PERMISSION variable, then drops it for JSON. Surfacing it adds zero permission lookups.
2. GraphQL needs no schema change. Contentlets are exposed through the _map JSON scalar (ContentFields:89 → ContentMapDataFetcher), which the client SDK spreads verbatim (transforms.ts:129). One server-side line reaches both /api/v1/page/json and GraphQL — and the SDK's query is unchanged.

The chain, and where each link landed:

Link	Change
Backend	PageRenderUtil — permission onto the contentlet map
GraphQL	none — flows through _map
SDK types	DotCMSBasicContentlet.canEdit, DotContentletAttributes['data-dot-can-edit']
SDK emitter	getDotContentletAttributes stamps the attribute
React wrapper	none — already spreads the attribute object
Angular wrapper	one host binding (it enumerates rather than spreads)

Still out of scope: a typed canEdit field on the contentlet GraphQL type. Only the SDK's named-field query variant (DEFAULT_PAGE_CONTENTLETS_CONTENT) would need it, and nothing requires that today.

Kept in this PR rather than split out at the author's request — review capacity is the binding constraint, and shipping the traditional gate while headless stays open repeats the "close one door, leave three open" problem.

Verification after the amendment

Check	Result
dotcms-core build	BUILD SUCCESS
dotcms-integration test-compile	BUILD SUCCESS
openapi.yaml	unchanged — no REST annotations touched
sdk-uve / sdk-angular / sdk-react	117 / 246 / 138 passed
portlets-edit-ema-portlet	1446 passed, 5 skipped
format:check + lint	clean

The integration test has not been executed locally — it needs Postgres + Elasticsearch. It will run for the first time in CI.

Additional Info

• This PR is now genuinely full-stack. One Java file plus one integration test, so the Area : Backend label is now accurate rather than an artifact of the bundle path.
• CI heads-up: the regenerated dotCMS/src/main/webapp/ext/uve/dot-uve.js matches the backend glob in .github/filters.yaml:29 (webapp/!(html|WEB-INF)/**), not the frontend one. So this substantively frontend-only PR will run the full integration and Postman suites and be labeled Area : Backend — expected, per ADR-0013, not a misconfiguration.
• SDK version untouched — ADR-0019 leaves @dotcms/uve versioning to the release pipeline.
• Two vacuous tests were caught and rewritten during development (one missing a getContentType mock, one where the page-asset swap never fired). Two harness gaps were fixed: mockInlineEditService lacked handleInlineEdit, and jest.spyOn over a useValue mock recorded zero calls.

Videos

video-1.mov

video.mov

Fixes: #37376

🤖 Generated with Claude Code

[claude]

Claude finished @rjvelazco's task in 3m 48s —— View job

---

Code Review — PR #37412

Reviewed the full diff against origin/main (backend PageRenderUtil, SDK emitter/types, and the four portlet guard points). One finding worth a look before merge; the rest of the implementation is sound and the fail-open reasoning is consistent throughout.

New Issues

• 🟡 Medium: core-web/libs/portlets/edit-ema/portlet/src/lib/services/dot-uve-actions-handler/dot-uve-actions-handler.service.ts:415 — Reading contentWindow?.document can throw on a cross-origin iframe rather than fail open. The optional chain guards only a null window; once contentWindow is a real Window on a different origin, accessing the .document property triggers a SecurityError (DOM cross-origin access), so the exception is thrown before canEditContentletByInode ever runs its !doc fail-open branch. The rest of the codebase avoids this by using iframe.contentDocument (which returns null cross-origin) — e.g. dot-uve-iframe.component.ts:243 — but this call uses the throwing window.document form.

  This matters precisely for the headless scenario this PR adds: headless pages load via the iframe src URL (dot-uve-iframe.component.ts:165/177 — src()), which can be a different origin, whereas traditional pages use same-origin srcdoc/contentDocument. When a Block Editor inline-edit postMessage arrives from a cross-origin headless page, handleInlineEditingEvent would throw instead of gracefully allowing the edit — the opposite of the stated fail-open contract, and the sidebar path doesn't even need document access to function.

  Suggested guard so the fail-open path is actually reached:

  let doc: Document | null = null;
  try {
      doc = contentWindow?.document ?? null;
  } catch {
      doc = null; // cross-origin headless page — fall through to fail-open
  }
  if (!canEditContentletByInode(doc, data?.inode)) { ... }

  Assumption: cross-origin property access throws synchronously (standard browser behavior) and the Block Editor inline flow is reachable on a cross-origin headless page. What to verify: load a headless page served from a different origin than the dotCMS admin, trigger a Block Editor inline edit, and confirm it isn't broken by an uncaught SecurityError. If headless pages are always same-origin-proxied in UVE, this is moot. Fix this →

Notes (non-blocking, no action required)

• PageRenderUtil.java:338-347 — Correct. contentlet here is a per-request transformer copy (transformer.hydrate().get(0), line 321), not a shared/cached instance, so writing the per-user canEdit into getMap() carries no cross-user leak risk, and it reuses the already-computed permission value — zero extra lookups, as the comment claims.
• Fail-open is applied consistently (!== 'false' / !== false) across dom.utils.ts, contentlet-permission.ts, and all component computeds — verified against the SDK types being optional (canEdit?: boolean).
• The two defense-in-depth guards in edit-ema-editor.component.ts (handleOpenQuickEdit, and the pencil/style handlers) read canEdit from different sources (editorSelected().payload vs $contentletEditData()) — intentional and consistent.

Everything else in the diff is clean.

_{· issue-37376-uve-edit-pencil-permission-implementation}