Member types: Implement containers

[ronaldbarendse]

PR #16914 got merged and targeted for v17, but only contains a partial implementation of PR #14833 that targeted v13 (but was closed).

This fixes the error when creating a new member type folder using the Management API (thrown from EntityContainer), updates the no-op IMemberTypeContainerRepository implementation to inherit from the shared base container repository (so something actually gets persisted) and updates/adds the required member type container API endpoints.

All the /umbraco/management/api/v1/member-type/folder endpoints now work and the /umbraco/management/api/v1/tree/member-type one returns the folders as well. However, the backoffice UI still needs to be updated to support the folders (hence I'm currently creating this as a draft PR):

[AndyButland]

I've extended this now to add the client-side support, and also aligned further with media types such that we have features to move, duplicate, export and import. Seemed like it might be a bit dangerous to have a management API that supports features that the UI doesn't, in case some uses this - e.g. via the MCP Server - to create things they can't then use. And this way we can hopefully roll forward rather than roll back.

I've moved the target branch to main though as think this will need to come in 17.1 to give time for review and testing, and not add something late to the 17 release candidate.

[Copilot]

Pull Request Overview

This PR adds folder support to the member type tree in Umbraco CMS, bringing it in line with functionality already available for document types and media types. The changes enable hierarchical organization of member types through folders.

Key changes include:

• Added folder entity type (UMB_MEMBER_TYPE_FOLDER_ENTITY_TYPE) and container support for member types
• Implemented folder creation, update, delete, move, duplicate, import, and export operations
• Added tree endpoints for ancestors, children, and siblings with folder filtering
• Updated the member type tree to support both folders and member types as tree items

Reviewed Changes

Copilot reviewed 106 out of 106 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/Umbraco.Web.UI.Client/src/packages/members/member-type/entity.ts	Added new folder entity type constant
src/Umbraco.Web.UI.Client/src/packages/members/member-type/tree/types.ts	Updated tree item model to support folder entity types
src/Umbraco.Web.UI.Client/src/packages/members/member-type/tree/server-data-source/*	Created new server data source implementation with full tree support
src/Umbraco.Web.UI.Client/src/packages/members/member-type/tree/folder/*	Added complete folder workspace, repository, and manifest implementation
src/Umbraco.Web.UI.Client/src/packages/members/member-type/entity-actions/*	Added move, duplicate, import/export actions for member types
src/Umbraco.Infrastructure/Persistence/Repositories/Implement/MemberTypeContainerRepository.cs	Replaced no-op implementation with actual entity container repository
src/Umbraco.Core/Services/ContentTypeEditing/MemberTypeEditingService.cs	Updated to support container (parent folder) during creation
src/Umbraco.Cms.Api.Management/Controllers/MemberType/*	Added API controllers for move, import, export, and tree operations

[ronaldbarendse]

I've moved the target branch to main though as think this will need to come in 17.1 to give time for review and testing, and not add something late to the 17 release candidate.

Totally understandable, although I'd then suggest merging ac20b43 and b9a5fd5, so at least the service works and Deploy can add support for it by targeting CMS 17.0.0. Maybe some base classes of the controllers can already be updated as well, so those don't end up as breaking changes. As long as the tree API endpoints don't return the containers/folders yet, the UI will simply not show them yet and nothing in the CMS will seem 'broken'.

[AndyButland]

Added in #20715 @ronaldbarendse. I found I couldn't make the controller base class changes and be compatible with the current front-end.

[ronaldbarendse]

Thanks Andy! Including those changes in the next 17 RC should allow us to implement deploying member type containers/folders in Deploy and introduce the remaining UI work in a future minor 💪🏻

I had a quick look at changes to the existing base classes and the following changes shouldn't be breaking:

• MemberTypeTreeControllerBase: changing NamedEntityTreeControllerBase<MemberTypeTreeItemResponseModel> to FolderTreeControllerBase<MemberTypeTreeItemResponseModel> while also implementing the newly introduced abstract FolderObjectType property isn't breaking, as it only introduces a new type into the hierarchy (see 'Introducing a new base class')..
• CreateMemberTypeRequestModel: changing CreateContentTypeRequestModelBase<CreateMemberTypePropertyTypeRequestModel, CreateMemberTypePropertyTypeContainerRequestModel> to CreateContentTypeWithParentRequestModelBase<CreateMemberTypePropertyTypeRequestModel, CreateMemberTypePropertyTypeContainerRequestModel> also only introduces a new type into the hierarchy.
• MemberTypeTreeItemResponseModel: changing NamedEntityTreeItemResponseModel to FolderTreeItemResponseModel does the same.

The remaining changes should be made backwards compatible using default implementations or adding additional overloads. We might want to already add the optional foldersOnly request parameter to the existing API controllers though, as adding new parameters still is a breaking change, regardless of adding a default value:

• RootMemberTypeTreeController.Root(..., bool foldersOnly = false)
• SiblingMemberTypeTreeController.Siblings(..., bool foldersOnly = false)

[AndyButland]

Thanks @ronaldbarendse - I've added those last two to #20715

[ronaldbarendse]

I've also reviewed the code and couldn't find any obvious issues, but did experience the following when testing in the backoffice:

• Moving an item from a folder back to the root works, but besides the green 'Moved' notification, also shows a red 'Menu loading failed. Showing the first items again.' error and doesn't update the tree.
• Performing a manual 'Reload children' on the tree root will show '...' at the bottom, which only shows the actual items after clicking/expanding it.
• Something similar happens when creating a new folder (but at the top, since folders are shown first).

Other than this, all actions (create, rename, move, delete, duplicate, export and import) do work as expected.

[AndyButland]

Thanks for the testing @ronaldbarendse. I saw issues similar to these, but I think they are outside of this PR:

• V17: Display an error message when opening a trashed content item and navigate around #20515
• V17 Unnecessary "Show more" button displays after sorting children in Content section #20676

[madsrasmussen]

The frontend changes look good. We need to be aware that there is a fair bit of code duplication, especially around the import/export of content types. It would be good to make that reusable at some point. But let's get this merged first, as there's already more than enough happening. 😃

@nikolajlauridsen, feel free to merge after you've had a look.