Content Types: Page through all allowed content types rather than stopping at the first 100 (closes #23512)

[AndyButland]

Description

A Document Type that allows more than 100 child Document Types only offered the first 100 in the Content section's Create dialog. Perhaps an edge case setup, but we should support retrieving all, similar to what we did recently for languages in #22765.

Fixes #23512

There were three separate issues to resolve.

1. The client never paged (the user-visible cause)

requestAllowedChildrenOf had no paging parameters anywhere in the chain — data source, interface or repository. It fired a single request with no skip/take, so the server applied its default take of 100, and every one of the 8 consumers read data.items while discarding the total the server correctly reported. Two of them carried a // TODO: implement pagination, or get 1000?.

Fixed by paging through the full set with the fetchAllPages helper added in #22765 for the >100 languages case. This is additive, mirroring that PR's requestCollection / requestAllItems split:

• requestAllAllowedChildrenOf (new) pages until every item is retrieved — all in-repo callers now use it.
• requestAllowedChildrenOf gains an optional paging argument, so a single page can be requested. Its existing behaviour is unchanged for external consumers.

The paging?: UmbOffsetPaginationRequestModel shape matches UmbTreeChildrenOfRequestArgs and the search args rather than reintroducing bare skip/take, which were deprecated in 16.3.

This affects allowed at root as much as allowed children, and needs resolving for every content type with an allowed-children/allowed-at-root endpoint — document, media and member types. Members need no configuration to hit it: every member type is a root candidate.

2. The server paged incorrectly (a latent prerequisite)

ContentTypeServiceBase.GetAllowedChildrenAsync applied .Take(take).Skip(skip) — inverted. At skip=0 that is harmless, which is why it went unnoticed; at skip=100, take=100 it returned zero items while Total still reported the true count. Client paging could not work until this was corrected.

3. Media-type siblings, same failure class

requestMediaTypesOfFolders and requestMediaTypesOf hardcoded take = 100 against paged endpoints. The dropzone and the media picker's folder path intersect those lists with allowed children, so fixing only the allowed-children side would still have dropped valid options.

Testing

Automated

Automated coverage added client and server; solution should build and CI checks pass.

Manual

The page size is a constant, so temporarily lowering it means we need 6 Document Types rather than 101.

Setup — temporarily set the page size to 5:

1. In src/Umbraco.Web.UI.Client/src/packages/content/content-type/repository/structure/content-type-structure-repository-base.ts, change:

   const ALLOWED_CHILDREN_PAGE_SIZE = 100;   // →  5

2. For the media steps, do the same in src/Umbraco.Web.UI.Client/src/packages/media/media-types/repository/structure/media-type-structure.repository.ts:

   const MEDIA_TYPE_PAGE_SIZE = 100;         // →  5

3. Run the site and open the backoffice with the browser network tab filtered to allowed.

While the page size is lowered, four of the client unit tests fail (expected [ Array(30) ] to deeply equal [ Array(2) ]) — they assert two requests at the real page size of 100, and 150 mock items at a page size of 5 is 30 requests. Expected, and resolved by the teardown step.

Server-side check (needs no Document Types at all beyond a parent with 6 children). In Swagger, call GET /umbraco/management/api/v1/document-type/{id}/allowed-children?skip=5&take=5. It returns the remaining item(s) with the full total. On v17/dev today the same call returns an empty items array with a non-zero total — that is defect 2.

Allowed children:

4. Create 6 Document Types, and a parent Document Type that allows all 6 as children.
5. Create a page of the parent type, then choose Create beneath it.
6. All 6 appear. The network tab shows two requests: skip=0&take=5 then skip=5&take=5.

Allowed at root:

7. Tick Allow at root on all 6 Document Types.
8. Choose Create on the Content tree root.
9. All 6 appear, over two allowed-at-root requests.

Members (no configuration needed — every member type is a root candidate):

10. Create 6 Member Types, then choose Create in the Members section. All 6 appear.

Media:

11. Repeat steps 4–9 in the Media section with 6 Media Types.
12. With 6 folder Media Types configured, open a Media Picker and confirm folders still render as folders (not as files) and the create folder options are all present.
13. Drag a file into the Media section whose only valid Media Type sits past position 5 in the allowed list, and confirm the upload is accepted.

Collection views: with the parent type allowing 6 children, open its collection (list view) and confirm the Create dropdown offers all 6.

Teardown: revert both page-size constants to 100.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[claude]

Claude finished @AndyButland's task in 10m 5s —— View job

---

Code Review Complete

• Read review skill instructions
• Gather PR diff and changed files (26 files: 1 C#, 22 TS, 3 integration test)
• Review C# backend changes
• Review TypeScript frontend changes
• Review test coverage
• Post inline comments for findings
• Post summary comment
• Apply labels (area/frontend, area/backend)

Summary: No critical issues. One important gap (no TS test for UmbMediaTypeStructureRepository's conditional paging logic). Two suggestions (comment on intentional skip=0 boundary test; || vs ?? in mock utility). Overall verdict: Approved with Suggestions for improvement.

[claude]

PR Review

Target: origin/v17/dev | Based on commit: 4cc8d53

Fixes two independent bugs causing the Create dialog to silently truncate at 100 allowed types: an inverted Skip/Take in ContentTypeServiceBase.GetAllowedChildrenAsync (zero items returned for any skip > 0), and client-side repository methods that never sent paging parameters. Both sides are corrected with automated tests.

Modified public API:

• UmbContentTypeStructureRepository interface: requestAllowedChildrenOf widened; requestAllAllowedChildrenOf? added as optional
• UmbContentTypeStructureDataSource: getAllowedChildrenOf gains optional paging
• UmbContentTypeStructureRepositoryBase: new requestAllAllowedChildrenOf concrete method
• UmbMediaTypeStructureRepository: requestMediaTypesOf/requestMediaTypesOfFolders now page through all results when no explicit skip/take is supplied

Affected implementations (outside this PR): Third-party classes implementing UmbContentTypeStructureRepository or UmbContentTypeStructureDataSource (both exported from @umbraco-cms/backoffice/content-type). Changes are additive so no compile-time break.

Other changes: MSW mock handlers now respect skip/take query params - any Storybook story relying on >100 items without explicit pagination will now only receive the first page.

---

Critical

None.

Important

media-type-structure.repository.ts:63 - No TypeScript test for the requestMediaTypesOf/requestMediaTypesOfFolders conditional paging logic. Both are publicly exported from @umbraco-cms/backoffice/media-type and their new fetch-all-vs-single-page branching is untested. document-type-structure.repository.test.ts covers only the base-class path. A test (no args two paged requests for 150 items; explicit skip/take one request) would give the same fail-before guarantee the C# tests have.

Suggestions

ContentTypeServiceTests.cs:2723 - Can_Get_First_Page_Of_Allowed_Children (skip=0) passes regardless of the bug since Take().Skip() and Skip().Take() are equivalent at skip=0. A short inline comment would preserve this rationale in the test file without requiring a PR description lookup.

mocks/utils.ts:67 - The || operator in Number(url.searchParams.get('skip')) || 0 treats numeric 0 as falsy, so the default applies by coincidence for skip=0. Null-coalescing before Number() communicates intent more clearly. Same for the take line.

---

Approved with Suggestions for improvement

Solid, well-scoped fix on both sides. The C# one-liner is exactly right, the TypeScript paging approach follows the established fetchAllPages pattern, and the test suite directly verifies the specific failure modes described. The only meaningful gap is TS-side coverage for UmbMediaTypeStructureRepository's conditional paging logic.

[sonarqubecloud]

Quality Gate passed

Issues
2 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

[nikolajlauridsen]

Backend changes looks good.

Also did all the manual tests, and they all looked great 👍