We have moved to GitHub Issues
Created by Jeroen Breuer 25 Jun 2012, 07:29:38 Updated by Sebastiaan Janssen 25 Aug 2013, 15:22:41
Relates to: U4-1468
It would be great if a node could change it's document type. In that case properties might also be removed, but the ones with the same alias can be mapped over.
I would add some UI that allows you to map properties with a different alias also
This is such a requested feature I would recommend a two-stage approach:
The only reason to jump right to step 2 is if it's so easy to do there's no reason to stop at step 1. But I suspect it's a fair amount of work and so I recommend a two-stage approach. Not everything has to be done in one shot to still be very helpful.
Step 2 could be really simple. Mapping is just a matter of listing all document properties of both the source and target doctype as you can see in the attached picture where I map database columns against the document type properties for CMSImport. The only thing that is difficult is when datatypes are different like the source is text and you want that against the uComponents MNTP datatype. Don't think that needs to be supported ;-)
I think that this together with [http://issues.umbraco.org/issue/U4-43 Multiple inheritance of doc types ]are the most requested features.
I think Richard has just volunteered for the job :)
It is great to see this with an estimated arrival in 4.10.0. I would like to throw in a suggestion that however this is done, a way to convert multiple nodes all at once, in bulk, would be incredibly handy. (To simplify how any property mapping is executed, assuming this is even going to be supported, you could insist all nodes to be converted are initially of the same type.) So you could say, convert all child nodes to a different doctype at once, or have a selection window with a bunch of checkboxes to select more than one at a time...
I think a common use case is when you already have a site built-out, and the client now decides they want some new thing to show up in just one section of the site (e.g., maybe an extra photo or an extra headline somewhere specifically on just these pages). You could either add this new property to your standard TextPage, but then it shows up everywhere, or otherwise you make a new doctype and then have to manually re-create every page again. In this scenario, I'd love to be able to convert the entire section at once from one doctype to another.
Also on this same note, and given some other current ideas being discussed for making Media behave more similarly to Content, let's not forget it would also be great to be able to change a Media node's type too!
Unfortunately, due to time constraints, we're going to have to move this feature to a later sprint.
This is available as a method on the new Content object as part of the new public api. void ChangeContentType(IContentType contentType); void ChangeContentType(IContentType contentType, bool clearProperties);
By default the differences in PropertyTypes between the DocumentTypes (ContentType in the API) will be removed, and the matching PropertyTypes will remain. Through the API there is an option to leave the Properties intact even though the new DocumentType doesn't have a corresponding PropertyType, but its important to note that this will leave the Property value as a type of orphan, as it has no corresponding PropertyType (and thus won't be visible in the backoffice) - it will however still be possible to retrieve the value.
Also note that even though this implementation is part of the Public API it won't be effective until the backoffice is changed to use the new underlying API in version 6.1.0.
Hi Morten, this is exciting news!
Regarding the behavior you mention where "orphaned" property values won't be seen in the backoffice, but will still exist and be available for retrieval on the front-end, this behavior shouldn't be surprising since the same thing has always happened I think when you delete a property from a document type---existing values on all previously-published content nodes will persist just like you mention.
On one hand, this seems not so bad, since you may later change the document type back to what it originally was, and don't want to risk accidentally deleting something important. On the other hand, one just needs to remember when coding the front-end to not assume just because a certain value is present, that it really belongs to the type of document you expect. Not a bad trade-off I think.
Great work and I look forward to 6.1.0!
Currently testing UmbracoCms.6.0.0.build.94 and in this version the backoffice is already changed to use the new underlying API so I guess this will be part of 6.0.0 instead of 6.1.0. However I don't see any way yet to change the Document Type of a Node yet. Perhaps it's possible with the API, but it might be better to open this issue again until it's also possible to do this in the UI. Perhaps doing it through the UI could be added as a feature for the new UI ("Belle").
Yup, its part of the underlying new public api. But the UI part of this feature won't be added in version 6, so the feature is only available 'programmatically'.
Should I create a new issue for the UI part or can we open this issue and set the due in version to 7.0.0?
Does it use events where you can hook into? PropertyConverting, PropertyConverted, NodeTypeConverting etc?
@Jeroen I think its a good idea to open a new feature request for the UI part of this feature. That would allow us to schedule it for Belle or maybe a 6.x release. I would also encourage the community to contribute with this, as it should be fairly straight forward to implement (its just not part of our priority list at the moment).
@Richard Changing the doc type of a document is done using a method on the new IContent object, and in order for it to take affect you would have to save it. So the only event that is currently being triggered is the Saving/Saved events, but they are of course not specific to the operation of changing doc type for a document. But please feel free to add a feature request or send us a pull request if you have something specific in mind ;)
@Morten I'm surprised at you saying changing doc type is "not part of our priority list" as it seems to be one of the most requested features.
@Dan Its only the UI part though. Its a resource issue on our part, and more or less the same reason the DocumentType Container-feature was also postponed. For both these features the code is actually in place in the new API, but we currently don't have the necessary resources to finish it of by doing the UI part of it unfortunately. One thing is to implement it in the new api, then there is the part of also making it available in the old api and then doing the UI part of the implementation. Right now we are refactoring the old api to use the new api under the hood, which should make the second part "easier" and leaving the UI part - which we don't have time for in this iteration. Hope this makes sense.
Added new issue for the UI part: http://issues.umbraco.org/issue/U4-1468
It's really disappointing to hear that the critical part of this (the UI) is "not part of our priority list" and "Its only the UI part though" ... this is the important part .. there is little sense in releasing a new feature that no one can use!
I don't see why the UI is so essential. Surely most people changing a doc type are willing to re-enter the appropriate information. For me that is a nice-to-have borderline-unnecessary feature - I guess it depends on the confidence level of the user though.
My only worry is that there is a bunch of unsafe code in the property editors which they get null or an incorrectly formatted value for a property will blows up - rendering the node un-fixable. That has happened to me a couple of times and I've had to hack the DB to fix the property value so the node would be editable in the back-office again.
The UI for this will be available in 6.2.0, see U4-1468 and the discussion on the dev mailing list here https://groups.google.com/d/msg/umbraco-dev/g0oMTUCTbDY/wGtl19ZD5A4J
Type: Feature (planned)
Assignee: Morten Christensen
Backwards Compatible: True
Affected versions: 6.0.0, 6.1.0
Due in version: 6.0.0