U4-1394 - DocumentType "Allowed Templates" will not update

Created by Rusty Swayne 05 Jan 2013, 19:27:07 Updated by Morten Christensen 14 Jan 2013, 14:12:54

Relates to: U4-1460

1/5 nightly build 11486289


When attempted to add or remove an existing template to an existing documenttype the change does not save.

2 Attachments

Download doctype-templates-save.patch

Download default-template.patch


Sebastiaan Janssen 07 Jan 2013, 10:58:30

Yup, can reproduce.

Andy Butland 07 Jan 2013, 22:00:21

Had a look at this. Seems to be that the allowed and default templates are saved in a user control, and that's missing a .Save() now this is required with the new API. Very tiny patch attached.

Andy Butland 08 Jan 2013, 06:55:22

Actually, this doesn't solve all issues. There's still the following:

Given a set-up with one doc type and two templates (A + B), with both allowed and template A selected as default. Switch default template to B and save. Reload the node. Default template has changed OK but A is no longer selected as allowed.

It's happening because in umbraco.cm.businesslogic.web.DocumentType the DefaultTemplate property setter is first calling RemoveDefaultTemplate(), which in turn calls Umbraco.Core.Models.ContentType.RemoveTemplate() and remove the template from the allowed list as well.

Morten Christensen 08 Jan 2013, 12:41:22

After looking into this it was pretty clear that I had placed the RemoveTemplate call in the RemoveDefaultTemplate method, as it shouldn't completely remove the template from the list of allowed templates but just remove it as default. So this should be fixed now.

Andy Butland 08 Jan 2013, 21:23:31

Still don't think is quite right Morten - so I've taken the liberty of reopening - hope that's OK.

With the setup described above one doc type and two templates (A + B), with A as default. If I switch the default to B this doesn't save - A remains as the default.

It stems I believe from the fact that the SQL to get a single content type will return more than one record - one for each allowed template. There was a TODO on ContentTypeRepository.GetBaseQuery() so I think this had been noted.

In the patch I've just ordered by IsDefault descending, so when you read the first record the default template will be set to the right one. This seems to sort the issue.

Sebastiaan Janssen 09 Jan 2013, 06:59:49

Thanks Andy, fixed in changeset 27bf6a24c818

Morten Christensen 09 Jan 2013, 08:12:44

Hi Andy, its perfectly fine to re-open an issue. Especially if it hasn't been properly fixed ;) Unfortunately my testing was done before a part of the base query for doc types was changed, so thanks for supplying a fix.

Rusty Swayne 13 Jan 2013, 03:32:41

I do not think this has not been completely resolved in the BETA downloaded from codeplex today.

If one tries to save a DocumentType that has never had an associated template, meaning no template selected there is still a foreign key constraint violation.

The INSERT statement conflicted with the FOREIGN KEY constraint "FK_cmsDocumentType_cmsTemplate". The conflict occurred in database "umbraco6beta", table "dbo.cmsTemplate", column 'nodeId'. The statement has been terminated.

The problem is either the templateNodeId in the cmsDocumentType table does not allow null values or if no template is selected the create/update to the cmsDocumentType table is still called. I am unclear as to whether the record in the cmsDocumentType table is intended to be there with a null value for templateNodeId or if the api should delete the record from the table when no template is selected.

I think this can be replicated by simply creating a new ContentType (DocumentType) and unchecking the "Create Matching Template" checkbox. This, in my upgraded from 4.11.2 project, will actually prevent the ContentType from being created.

Our quick fix has been to add an empty dt-save-fix.cshtml template and insert a record into the cmsDocumentType table associating the empty template with an ContentTypes that were added in 4.11.2 and simply allowing a new template to be created when adding anything new, then change the template to the dt-save-fix.cshtml and deleting the newly created template so that we only have a single template to delete when this issue is patched.

I don't think this has any relevance to the issue but we are using Mvc layouts rather than the default master pages.

Morten Christensen 13 Jan 2013, 08:32:42

Okay, thanks for reporting back. I'll look into it. Sounds like it should be fairly straight forward to reproduce the issue.

Morten Christensen 14 Jan 2013, 14:12:49

I tracked done this issue to a missing foreign key for fresh installs, which was why we didn't catch this issue before. I then corrected the logic in the ContentTypeRepository a bit, so a template with an Id of zero won't be saved. I tested this with having a DocType with no templates, and then adding one then one more to verify the behaviour. So I believe this issue is now finally fixed :)

Priority: Major

Type: Bug

State: Fixed

Assignee: Morten Christensen

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 6.0.0

Due in version: 6.0.0


Story Points: