Paginate the user references tab against the new object-dependencies endpoint

[jcPimcore]

Changes in this pull request

Resolves: pimcore/platform-version#308 Studio UI
Resolves: pimcore/admin-ui-classic-bundle#1106 Studio UI

The user detail screen's "References" tab rendered the entire user.objectDependencies.dependencies array embedded in the GET /users/{id} response, reproducing the same unbounded-hydration OOM risk as pimcore/admin-ui-classic-bundle#1106 on the frontend.

• Regenerate the OpenAPI client (docs.jsonopenapi.json + user-api-slice.gen.ts) against the new paginated GET /user/{id}/object-dependencies endpoint added in pimcore/studio-backend-bundle.
• Rework references-container.tsx to page through the new endpoint with local page/pageSize state and a new components/pagination/pagination.tsx, following the same pattern already used by the generic element Dependencies tab's required-by-panel. Uses useTranslation() (not a direct i18next import) so translated text updates on language change, and a shared DEFAULT_PAGE_SIZE constant instead of a duplicated magic number.
• Add a dedicated USER_OBJECT_DEPENDENCIES cache tag in user-api-slice-enhanced.ts (instead of reusing USER_DETAIL), so editing/deleting a user doesn't force an unnecessary refetch of their object-dependencies pagination, mirroring the existing ELEMENT_DEPENDENCIES tag pattern.
• No breaking change: objectDependencies on the generated User type keeps its original dependencies/hasHidden fields exactly as they were; it only gains an additive totalItems field. Nothing in this repo's UI reads that field at all (the References tab always calls the new paginated endpoint directly), so this is purely a type-sync change with zero runtime UI impact.

Additional info

Full project tsc --noEmit and eslint both pass clean. The build was re-run locally multiple times after backend changes and verified byte-for-byte (checked for zero-byte/corrupted chunks, not just a clean exit code) to actually contain the current endpoint path/hook, not just the source.

All 6 Copilot review comments on this PR were addressed with real code/doc changes (translation-key description clarified on the backend side for the one that originated there).

Depends on pimcore/studio-backend-bundle's fix/308-paginated-user-object-dependencies.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a paginated “object dependencies” data source to the User References tab and wires it to a new RTK Query endpoint.

Changes:

• Introduces userGetObjectDependencies RTK Query endpoint + types.
• Updates References tab to fetch dependencies server-side and render pagination controls.
• Adds a dedicated Pagination component for the References tab.

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 6 comments.

File	Description
assets/js/src/core/modules/user/user-api-slice-enhanced.ts	Adds cache tags for the new userGetObjectDependencies endpoint.
assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx	Switches from draft-based dependencies to paginated API query + pagination UI.
assets/js/src/core/modules/user/management/detail/tabs/references/components/pagination/pagination.tsx	New pagination UI wrapper with loading/empty states.
assets/js/src/core/modules/auth/user/user-api-slice.gen.ts	Adds generated endpoint + response/arg types; updates user dependency preview typing.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (2)

assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx:51

• After the first response, RTK Query keeps isLoading false during page and page-size requests and reports those through isFetching. The grid therefore continues to present the previous page as settled while the next page is loading. Capture isFetching from the hook and use it for the table's loading state (the pagination can keep the initial-load flag if it must preserve its internal page-size state).

          isLoading={ isLoading }

assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx:50

• A failed dependencies request also produces data === undefined, so this fallback presents the failure as an empty references list and the API error is never reported. Capture error from the query and pass it to trackError(new ApiError(error)), following the user-management error-handling pattern.

          data={ data?.items ?? [] }

[Copilot]

Pull request overview

Copilot reviewed 6 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (2)

assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx:28

• The new RTK Query request does not handle failures. A 403/404/network error is therefore presented as an empty references table (and a zero-item pager) without being reported through the application's error handler. Capture isError/error and call trackError(new ApiError(error)), as other user-management requests do.

  const { id } = useUserManagementContext()
  const [page, setPage] = useState<number>(1)
  const [pageSize, setPageSize] = useState<number>(DEFAULT_PAGE_SIZE)

  const { data, isLoading } = useUserGetObjectDependenciesQuery({ id, page, pageSize })

assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx:51

• After the first successful request, RTK Query keeps isLoading false while a new page is fetched and exposes the previous data until that request completes. The pager therefore advances immediately while this table still displays rows from the old page with no loading state. Read isFetching from the query and pass it to the table (while keeping the pagination's initial-load handling unchanged) so stale rows are visibly pending.

        <Table
          data={ data?.items ?? [] }
          isLoading={ isLoading }

[jcPimcore]

Addressed both suppressed Copilot comments in f999c57 (rebased to 7cea893 after the auto-build bot):

• Query errors now go through trackError(new ApiError(error)) on isError, matching the established pattern elsewhere (use-user-management-draft.tsx, use-zip-download.tsx, custom-metadata-container.tsx) - previously a 403/404/network failure just showed an empty table silently.
• The table now uses isFetching instead of isLoading, so page/pageSize changes show a pending state instead of displaying stale rows from the previous page while the next one loads. Pagination keeps isLoading for its own initial-load skeleton.

Note: required-by-panel.tsx (the generic element Dependencies tab this was modeled on) has the same isLoading-only gap and no error handling either - left untouched as a separate, pre-existing component out of scope here.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Copilot reviewed 6 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (1)

assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx:59

• RTK Query keeps data from the last fulfilled argument while a newly selected page is pending or rejected. If page 1 loaded and the page 2 request fails, page remains 2 and isFetching becomes false, but this table renders page 1's rows as though they belonged to page 2. Use the hook's currentData for the rows (while retaining data separately if the pagination total should remain visible) so a failed page cannot display stale results.

        <Table
          data={ data?.items ?? [] }
          isLoading={ isFetching }
        />

[jcPimcore]

Confirmed and fixed in b97d50f (rebased to f90e04c after the auto-build bot). Verified the claim directly against the installed RTK Query type definitions rather than taking it on faith: currentData is documented there as "only populated for the current query arguments," while data retains the last fulfilled result across arg changes - exactly the stale-page-on-failure scenario described.

The table now reads currentData?.items (empty/undefined during a pending or failed fetch for the current args, correctly covered by the isFetching loading state) while Pagination keeps data so the last-known totalItems doesn't reset during a transient failure - the compromise you suggested.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Copilot reviewed 6 out of 8 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (1)

assets/js/src/core/modules/user/management/detail/tabs/references/references-container.tsx:29

• The dependent endpoint counts all matching objects before applying each object's list permission, then filters unauthorized objects out of the selected page. As a result, this tab can show short or completely empty pages while the paginator reports a larger total (and can expose the exact count of hidden references). The backend should paginate and count the authorized result set, or return separate visible/hidden pagination metadata that this UI can represent accurately.

  const { data, currentData, isLoading, isFetching, isError, error } = useUserGetObjectDependenciesQuery({ id, page, pageSize })

[jcPimcore]

Per discussion, documented (not code-fixed) in pimcore/studio-backend-bundle@34d21edc: totalItems is a raw match count that never subtracts permission-denied objects, since accurately excluding them would require hydrating and checking every matching object across the whole dataset - exactly the unbounded cost this endpoint exists to avoid. That tradeoff is now stated plainly in the schema description, the totalItems property description, the endpoint's operation description, and the upgrade note: a page (or the embedded preview) can legitimately come back shorter than requested, or empty, while totalItems stays the same.

No frontend changes needed - this is purely a documentation-text change on the backend side.

🤖 Generated with Claude Code

[ValeriaMaltseva]

@jcPimcore
LGTM :)

As soon as pimcore/studio-backend-bundle#2011 is
merged, we can merge this one.

P.S. Please double-check that composer.json and docs.jsonopenapi.json are
updated properly.

[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