We have moved to GitHub Issues
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.
Yup, can reproduce.
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.
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.
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.
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.
Thanks Andy, fixed in changeset 27bf6a24c818
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.
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.
Okay, thanks for reporting back. I'll look into it. Sounds like it should be fairly straight forward to reproduce the issue.
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 :)
Assignee: Morten Christensen
Backwards Compatible: True
Affected versions: 6.0.0
Due in version: 6.0.0