V16: Siblings endpoints

[nikolajlauridsen]

Add siblings endpoints for all "umbracoNode" entities which allows for cursor based pagination

• Document
• Document types
• Document Blueprint
• Media
• Media types
• Data types
• Template

Testing

Ensure that each enpoint returns:

• The target item
• X amount before
• X amount after

[Copilot]

Pull Request Overview

Adds cursor-based “siblings” endpoints for all Umbraco node types by implementing a new GetSiblings method in the repository, wiring it through the service layer, and exposing it via controller endpoints.

• Implements GetSiblings in EntityRepository using SQL window functions.
• Extends IEntityService/EntityService with a GetSiblings method and a default interface stub.
• Adds controller classes under each tree folder to expose the new siblings endpoint.

Reviewed Changes

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

Show a summary per file

File	Description
src/Umbraco.Infrastructure/Persistence/Repositories/Implement/EntityRepository.cs	Adds GetSiblings, a PerformGetAll overload, and SQL-building logic.
src/Umbraco.Infrastructure/Persistence/NPocoSqlExtensions.cs	Introduces an AppendSubQuery extension for NPoco.
src/Umbraco.Core/Services/IEntityService.cs	Declares GetSiblings in the service interface.
src/Umbraco.Core/Services/EntityService.cs	Implements GetSiblings in the service.
src/Umbraco.Core/Persistence/Repositories/IEntityRepository.cs	Adds the GetSiblings signature to the repository interface.
src/Umbraco.Cms.Api.Management/Controllers/**/Siblings*TreeController.cs (multiple)	Adds new controller endpoints for siblings per entity type.

Comments suppressed due to low confidence (3)

src/Umbraco.Infrastructure/Persistence/Repositories/Implement/EntityRepository.cs:148

• No tests have been added for the new GetSiblings method. Consider adding unit or integration tests to cover cursor‐based pagination and edge cases (e.g., no siblings, fewer siblings than requested).

    public IEnumerable<IEntitySlim> GetSiblings(Guid objectType, Guid targetKey, int before, int after, Ordering ordering)

src/Umbraco.Infrastructure/Persistence/Repositories/Implement/EntityRepository.cs:198

• The statement return []; is invalid C# syntax. You can return an empty sequence with Enumerable.Empty<IEntitySlim>() or new IEntitySlim[0].

            return [];

src/Umbraco.Core/Services/IEntityService.cs:178

• Default implementation using => []; is invalid. Use => Enumerable.Empty<IEntitySlim>() to return an empty sequence.

        Ordering? ordering = null) => [];

[Migaroez]

Code review completed: Pushed some changes for minor tweaks and left a comment for unit test rework.

[Migaroez]

Functional Review complete: Works as described.

Wondering whether we should be exposing the ordering mechanic upto the endpoints so people can order by name/createdate and so on. Might be something handy for the Orchestration project?

[nikolajlauridsen]

Wondering whether we should be exposing the ordering mechanic upto the endpoints so people can order by name/createdate and so on. Might be something handy for the Orchestration project?

I chose to align it with the existing Children endpoints, which don't expose the order either. Additionally, I feel it might be a bit beyond what the endpoint is really for, since it is tied to "our" trees and how we've decided they should function, for instance, that the content type tree is not orderable (it doesn't respect sort order).

Currently, you would have to create your own "tree" by extending the XTreeControllerBase and changing the ItemOrdering property.

However, I think you raise an excellent point. Come to think of it, in reality, how your tree should be ordered is very much a frontend concern, and should be controlled by the frontend. However, I think this should a general thing across all tree endpoints, not just the siblings one, so I'd rather have consistency, and leave it out for now, and then create a set of V2 tree endpoints which puts the ordering of trees in the hand of the frontend. Definetely something to bring up with the team.

TL;DR: I like your idea, I think you're right, but I think we should do this consistently across all tree endpoints in a V2 endpoint.

[Migaroez]

Wondering whether we should be exposing the ordering mechanic upto the endpoints so people can order by name/createdate and so on. Might be something handy for the Orchestration project?

I chose to align it with the existing Children endpoints, which don't expose the order either. Additionally, I feel it might be a bit beyond what the endpoint is really for, since it is tied to "our" trees and how we've decided they should function, for instance, that the content type tree is not orderable (it doesn't respect sort order).

Currently, you would have to create your own "tree" by extending the XTreeControllerBase and changing the ItemOrdering property.

However, I think you raise an excellent point. Come to think of it, in reality, how your tree should be ordered is very much a frontend concern, and should be controlled by the frontend. However, I think this should a general thing across all tree endpoints, not just the siblings one, so I'd rather have consistency, and leave it out for now, and then create a set of V2 tree endpoints which puts the ordering of trees in the hand of the frontend. Definetely something to bring up with the team.

TL;DR: I like your idea, I think you're right, but I think we should do this consistently across all tree endpoints in a V2 endpoint.

Can you add some tasks to the internal backlog so this can be considered for the future?