[2026.3][Class] Require objects permission for the custom layout editor collection route

[jcPimcore]

Resolves pimcore/platform-version#597

Problem

Since 2026.3.0, users with the objects permission but without classes get a 403 on GET /class/custom-layout/editor/collection/{objectId} whenever they open a data object, so the editor shows repeated "no permission" dialogs.

Cause

EditorCollectionController was switched to CLASS_DEFINITION together with the custom layout admin routes. It is not an admin route: the data object editor calls it on every object open to determine the available layouts.

Fix

EditorCollectionController requires DATA_OBJECTS again. This is safe because the route is read-only and CustomLayoutService::getCustomLayoutEditorCollection() already:

• loads the object via getDataObjectElement(), which requires view permission on the object, and
• filters layouts to the user's allowed layouts for non-admins.

All other custom layout controllers keep requiring CLASS_DEFINITION.

Tests

• CustomLayoutControllerPermissionTest: EditorCollectionController removed from the CLASS_DEFINITION provider and covered by a separate DATA_OBJECTS assertion; the other controllers are still asserted as CLASS_DEFINITION.
• Ran in Docker (php8.4): the test failed before the fix (classes vs objects); the full Unit suite passes (1269 tests) after it.
• Not run locally: php-cs-fixer / PHPStan (left to CI). No functional API test was added, because the existing Postman collections don't cover custom layouts.

Notes

• BC: none. Only the permission on an @internal controller changes; the response is unchanged.
• Needs forward-merging to 2026.x.
• Follow-up outside this PR: the UI reports the error on every render in useCustomLayouts (studio-ui-bundle), which multiplies the dialogs.

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🔵 Needs a closer look

The focused fix appears correct, but changing an authorization boundary warrants final maintainer security review.

Review effort: Balanced
Findings: None

What changed in this PR

Verdict: Request review. No blocking code issues found.

Restores data-object editor access to custom layouts for users without class-management permission.

Changes:

• Requires DATA_OBJECTS for the read-only editor collection route.
• Adds a focused permission regression test.
• Retains CLASS_DEFINITION on administrative custom-layout routes.

Assessment:

• Fixes the root cause at the route authorization boundary; object-view and layout filtering remain enforced by the service.
• No missed call sites or backward-compatibility breaks found.
• Test coverage targets the narrowest relevant seam.
• No documentation or changelog update is included; remaining risk is the security-sensitive permission change requiring maintainer validation.

Findings

None.

File	Description
src/​Class/​Controller/​CustomLayout/​EditorCollectionController.php	Restores DATA_OBJECTS authorization for editor layout discovery.
tests/​Unit/​Class/​Controller/​CustomLayout/​CustomLayoutControllerPermissionTest.php	Separately verifies editor and administrative route permissions.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

The new service test must use the branch’s current POCL license header before approval.

Review effort: Balanced
Findings: 1

Open (1)

• Use the current POCL license header · New

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud