[Grid] Fix 404 when grid search is anchored on the root folder

[xIrusux]

Problem

On studionightly, clicking a bar in the data quality score widget (drill-through) fails:

POST /pimcore-studio/api/data-objects/grid/CAR → 404
{"message": "DataObject with ID: 1 not found", "errorKey": "error_element_not_found"}

Root cause

The DQ drill-down grid is class-scoped, not folder-scoped, so the frontend anchors it on the root folder and sends folderId: 1 (which is also the only option — folderId is a required field of the grid request body).

GridSearch::setFilterPath() resolves that folderId through the permission-aware search index (getDataObjectById(1, $user) → GDI byId() with PermissionTypes::VIEW + the user's workspace query) purely to derive the path filter.

The root folder is not reliably visible through that lookup:

• Restricted users: the workspace query only matches elements under the user's allowed paths. For a user whose workspace starts below the root (e.g. read on /Product Data only), the root's path / matches nothing → null → NotFoundException('DataObject', 1) → the observed 404.
• Index state: a rebuilt/lagging index that misses the root document fails the same way.

This is why it worked in dev (admin user, root indexed) and broke in production.

Fix

The root folder always exists and its full path is / by definition — no lookup is needed. setFilterPath() now short-circuits for folderId === ElementFolderIds::ROOT->value and sets the path filter to / directly. This applies to all three element types (asset/object/document roots are all id 1).

Security note: the removed lookup acted as an implicit "can you see this folder" gate — but only for the root. The path filter / is pure scoping (matches everything); the result set is still filtered by the user's workspace query inside the search itself, so restricted users see exactly what they are allowed to see and nothing more. A user with no workspace gets an empty grid, not a 404.

Regression test

tests/Unit/DataIndex/Grid/GridSearchTest.php:

• folderId = 1 must not call the index lookup and must produce a / path filter (red before the fix — failed on the exact getDataObjectById(1, …) call from the production stack trace).
• folderId ≠ 1 still resolves the folder path through the index (pins existing behavior).

Verified: bundle unit suite green (418 tests, 966 assertions), PHPStan clean.

Propagation

setFilterPath() is byte-identical on 2025.4, 2026.1, 2026.2 and 2026.x — this needs the usual forward-merge up the chain (studionightly runs the newest line).

No frontend change needed: the DQ widget's ROOT_FOLDER_ID = 1 anchor becomes legitimate once the backend stops requiring root visibility.

🤖 Generated with Claude Code

[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

[codacy-production]

Up to standards ✅

🟢 Issues 4 medium · 11 minor

Results:
15 new issues

Category	Results
UnusedCode	1 medium
BestPractice	2 medium
CodeStyle	11 minor
Complexity	1 medium

View in Codacy

🟢 Metrics 4 complexity

Metric	Results
Complexity	4

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}