Templating: Creating a doctype with template now yields a strongly typed template (closes #20443)

[lauraneto]

Fixes #20443

In recent versions the flow of requests from the client when creating a document type with a template was:

1. Create a template.
2. Create a document type with the template id returned in 1.

In 1., the document type still didn't exist, so a "generic" template was being created.
Additionally, if the creation of the document type failed, the "orphan" template would remain.
This PR adds a new endpoint to the Management API:

POST /umbraco/management/api/v1/template/for-document-type
{
  "documentType": {
    "id": "b64e014a-2617-463c-9538-ed9c3d3f1ffc"
  }
}

This endpoint calls TemplateService.CreateForContentTypeAsync(), which is a new overload of an existing method, that accepts a content type id/key.

With the above in place, I adjusted the flow to:

1. Create document type (with no template)
2. Create template (and pass in the created document type id)
3. Update the document type to assign the template created in 2

This way, a template is only created if the content type was actually created, and the created document type id will be passed along so the generated template uses the right model.

Testing
Create a Document Type with Template and verify that the generated template references the typed model and looks the same as in V13.
Also, ensure that creating templates through the backoffice still works as expected.

[Copilot]

Pull Request Overview

This PR fixes a limitation in document type creation with templates, where the flow previously created a generic template first then the document type, leaving potential orphan templates if creation failed. The solution implements a new API endpoint to create strongly-typed templates for existing document types and reorders the creation flow.

Key changes:

• Adds new API endpoint POST /umbraco/management/api/v1/template/for-document-type to create templates for specific document types
• Reorders document type with template creation: create document type first, then template, then update document type
• Adds overloaded CreateForContentTypeAsync method accepting content type key instead of alias/name

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Umbraco.Web.UI.Client/src/packages/templating/templates/types.ts	Adds interface for template creation with document type reference
src/Umbraco.Web.UI.Client/src/packages/templating/templates/repository/detail/template-detail.server.data-source.ts	Implements client-side service method for new API endpoint
src/Umbraco.Web.UI.Client/src/packages/templating/templates/repository/detail/template-detail.repository.ts	Adds repository method with store integration for new template creation flow
src/Umbraco.Web.UI.Client/src/packages/documents/document-types/workspace/document-type/document-type-workspace.context.ts	Updates document type creation workflow to use new template creation method
src/Umbraco.Web.UI.Client/src/packages/core/backend-api/types.gen.ts	Generated type definitions for new API endpoint
src/Umbraco.Web.UI.Client/src/packages/core/backend-api/sdk.gen.ts	Generated client SDK method for new API endpoint
src/Umbraco.Core/Services/TemplateService.cs	Implements service method overload and adds constructor for dependency injection
src/Umbraco.Core/Services/OperationStatus/TemplateOperationStatus.cs	Adds ContentTypeNotFound status for error handling
src/Umbraco.Core/Services/ITemplateService.cs	Adds interface method for new template creation overload
src/Umbraco.Cms.Api.Management/ViewModels/Template/CreateTemplateForDocumentTypeRequestModel.cs	Request model for new API endpoint
src/Umbraco.Cms.Api.Management/OpenApi.json	OpenAPI specification for new endpoint
src/Umbraco.Cms.Api.Management/Controllers/Template/TemplateControllerBase.cs	Error handling for ContentTypeNotFound status
src/Umbraco.Cms.Api.Management/Controllers/Template/CreateTemplateForDocumentTypeController.cs	API controller implementation for new endpoint

[AndyButland]

Code all looks good. One query inline, but I think you can just read and close it.

Do you think you might look at an integration test for both of these CreateForContentTypeAsync overloads? I can see we have some tests of this service in TemplateServiceTests, but not covering these methods. Of course ideally the first overload would be already in place, but it's not, so perhaps it's a good time to add test coverage here.

Meantime I'll pull it locally and do some testing.

[AndyButland]

Another thought - would it be better to remove this new endpoint and instead extend the existing create one? So have CreateTemplateRequestModel take an optional public ReferenceByIdModel? DocumentType { get; set; }, and depending on whether that is provided call _templateService.CreateAsync() or _templateService.CreateForContentTypeAsync.

[lauraneto]

I guess that depends on whether we want to allow users to create the template after the document type has been created.
Not sure if that was an option in v13 or not, I will double check.

[lauraneto]

Just checked how this worked in v13.
You had both options:

• Create with the content type - which would add a parameter to the content type creation so it knew to create the template as well.
• Do it after - which would do a request to POST 'https://localhost:44340/umbraco/backoffice/umbracoapi/contenttype/PostCreateDefaultTemplate?id=1055', with id being the id of the content type.
  

[AndyButland]

We don't necessarily have to expose it in the UI even if the management API supports it (there are other clients of the API these days of course!).

My comment here though was more just about whether it's cleaner to have a single endpoint for creating templates, with a model that optionally allows you to provide the document type to create it for. Or to have, as you currently do in this PR, two endpoints, with two models - one for create a standalone template, and one for creating one for a document type.

[lauraneto]

Sorry, my confusion.
For a moment I was thinking that it was about adding an option to the endpoint that creates the document type.
I think that makes sense, my only doubt is what to do if you also provide content in the request, I'm guessing we would then ignore the provided content type key?

[AndyButland]

I see your point, and had missed that possibility. In which case I think it's better how you have it as two discrete endpoints. It's clear then you either have the option to a) create and populate a template or b) create an empty template for a document type. And avoids otherwise messy logic of the nature of "if this is provided ignore that".

[AndyButland]

Following local testing I can confirm this works as expected.

[lauraneto]

I will create a new branch and target v17.