Introduced sign providers for trees and implemented one for documents with schedule pending

[AndyButland]

Description

This PR proposes an implementation for server-side provision of backoffice "signs" (where we want to be able to show small icon overlays on nodes and entries indicating various states).

Internal reference: AB48452

This should include trees and collections - this PR targets only trees so we can agree the approach, and then a further one can be added for collections.

We need to ensure this is extensible for packages.

I've taken the approach of registering a collection of ISignProviders. When rendering trees, after retrieving a paged collection of tree item view models, this whole collection is provided to the registered providers which can add or remove signs.

These seems the most efficient approach, meaning an implementation of a sign provider has the option to retrieve all the data needed in one query, avoiding an N+1 concern if each were updated individually. Offering this server-side also avoids additional requests from the client.

In addition to the abstraction I've implemented a single provider that can be used to indicate which items in the tree have a pending publish scheduled.

Testing

Via a management API, make requests to retrieve document tree items, e.g. via:

/umbraco/management/api/v1/tree/document/children?parentId={id}

For items that have a scheduled publication saved, you should see this in the response:

    {
      ...
      "signs": [
        {
          "alias": "Umb.ScheduledForPublish"
        }
      ],
      ...
    },

If there are no signs an empty array will be returned.

Note that rather than a string, I've followed conventions in the management API to always return an object. All core aliases will be prefixed with Umb..

[Copilot]

Pull Request Overview

This PR introduces a sign provider infrastructure for server-side provision of backoffice "signs" (icon overlays) on tree nodes to indicate various states. The implementation targets document trees initially and includes a concrete provider for indicating scheduled publish status.

Key changes:

• Introduces ISignProvider abstraction with collection-based registration for extensibility
• Implements HasScheduleSignProvider to show scheduled publication status
• Updates all tree controllers to integrate with the new sign provider system

Reviewed Changes

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

Show a summary per file

File	Description
SignModel.cs	Defines the response model for sign data with provider and alias properties
ISignProvider.cs	Core abstraction defining tree sign provision operations
HasScheduleSignProvider.cs	Concrete provider implementation for scheduled publication signs
SignProviderCollection.cs/.Builder.cs	Collection infrastructure for registering and managing sign providers
EntityTreeItemResponseModel.cs	Base tree model updated with sign collection and manipulation methods
EntityTreeControllerBase.cs	Updated to integrate sign population in all tree endpoints
Various tree controllers	Updated constructors to accept SignProviderCollection dependency
IContentService.cs/ContentService.cs	New method to retrieve scheduled content keys
DocumentRepository.cs	Database query implementation for scheduled content retrieval

Comments suppressed due to low confidence (1)

src/Umbraco.Cms.Api.Management/Controllers/DataType/Tree/RootDataTypeTreeController.cs:6

• This removed import appears to be unrelated to the sign provider changes and may indicate accidental cleanup that could affect other functionality if this namespace was needed elsewhere in the file.

using Umbraco.Cms.Api.Management.ViewModels.Tree;

[AndyButland]

Looking good @NillasKA, I like the refactorings. I've added a few comments to look at, the main one being around seeing if we can optimise the new provider you've added for pending changes.

After that please can you also have a look to see if you can add tests for the new provider, like we have for the other two. Thanks.

[NillasKA]

Question for HasCollectionSignProvider

Im not allowing signs to be created on Collection Items, because DocumentCollectionResponseModel does contain a collection, so it wouldnt work. But i'm not sure, since technically an item can have a collection, even if itself is in a collection, so should DocumentCollectionResponseModel have that sign?