Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change a Document Type Missing in Umbraco 8 #5070

Open
mathewknott opened this issue Mar 25, 2019 · 12 comments

Comments

Projects
None yet
6 participants
@mathewknott
Copy link

commented Mar 25, 2019

I've posted the following on the forum

https://our.umbraco.com/forum/umbraco-8//96476-change-document-type-in-umbraco-8

--
I've noticed in Umbraco 8 there is no option to "Change Document Type" when editing a page in the tree (Under the menu Do Something Else).

Does anyone know if this feature will come back or if it's gone for good or if kind of work is recommended now to be handled in a different way.

It was a very handy and useful feature. I had feedback. I've copied the text below..

Hi Mathew It seems the action exists here, but has been commented out for now: https://github.com/umbraco/Umbraco-CMS/blob/dev-v8/src/Umbraco.Web/Actions/ActionChangeDocType.cs I guess it is because the old one was using WebForms and it needs to be re-written with Angular + Web API in Umbraco 8. The other actions have Angular views and controllers, which exits here: https://github.com/umbraco/Umbraco-CMS/tree/91c52cffc8b7c70dc956f6c6610460be2d1adc51/src/Umbraco.Web.UI.Client/src/views/content It would be great if you submit an issue here: https://github.com/umbraco/Umbraco-CMS/issues /Bjarne

@bjarnef

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

@mathewknott you should probably update the title to "Change a Document Type" instead of "Create a Document Type".

@mathewknott mathewknott changed the title Create a Document Type Missing in Umbraco 8 Change a Document Type Missing in Umbraco 8 Mar 25, 2019

@mathewknott

This comment has been minimized.

Copy link
Author

commented Mar 25, 2019

@mathewknott you should probably update the title to "Change a Document Type" instead of "Create a Document Type".

Thanks. Done.

@bjarnef

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

@kjac maybe this is something you want to have a look at? 😁😎🤓

@kjac

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

Geez Louise that's no small feat. I will ponder it for a few days 👍

@clausjensen

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

The feature was chosen not to be ported to v8 initially, as it was basically creating more issues for people than it actually fixed.

The short explanation is that when you change a document type of an item, you basically also get to decide what happens with the data stored in each property (what new property does this data get mapped into). Since this is a one-way-one-shot operation that happens when you do it it is not as such stored in any sort of history and we have no idea what you actually did, after you do it.

Considering this in a Umbraco Cloud scenario - if you had this item already deployed to your destination, redeploying the item where you have now changed the document type, things simply no longer match up:

We have this content item that is of type x .. and now you're trying to send me this same content item, but it is now of type y? - things aren't really matching up - I don't know where to put this data?

A solution could be to simply say - well .. if there's a mismatch between the existing item's doctype and the doctype of the item being deployed ... it is most likely the one being deployed we want to keep so we just delete the one on the destination and put up the new one with the correct properties.

In theory this should work. Then there's however some cases that we need to handle, such as .. what happens if this particular node has children? - we can't delete it then without temporarily moving the children elsewhere.

So based on the fact that this is potentially creating big issues for people in Cloud, we would (for now) rather that you either manually replicate your data over to a completely new node of the wanted doctype - or if you have a lot of content where you need to do this - create a script for moving data to new nodes of the new doctype.

We would however like to bring back this feature in the future - it has just not been prioritized yet. I'm marking this as a feature request, but until we have a decent solution that will not have people end up in bad situations on Cloud, I don't think we will be prioritizing merging anything in.

@kjac

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

I did a brief investigation of this and it really is a hornet's nest once you open it up. Specifically language variance makes it a really troublesome feature to implement in a way that makes complete sense to editors.

@clausjensen

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

@kjac oooh yes... I hadn't even considered that part. So.. yep.. my recommendation here is that noone should spend time working on this, as there will likely be a lot of unconsidered scenarios causing this to end up as a feature that will not get prioritized and merged for a very long time - which is just a bad experience for everyone 😢

It will hopefully some time in the future, be picked up by Core again with a proper process to make sure we cover all things.

@mathewknott

This comment has been minimized.

Copy link
Author

commented Apr 1, 2019

@kjac

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

As is the code from V7 is by no means sufficient for V8, taking into account the complexity of culture variance.

Until a solution can be thought up that doesn't cause irrevocable data loss in conversion between content of different culture variance in both content and property level, personally I'd rather be without.

@clausjensen

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

@mathewknott the feature has so far been disabled on Cloud projects (in v7) so yes - that would be a perfectly viable solution for v8 as well.

However as @kjac mentions - the code is not there. It is a completely different scenario when we have to factor in variants, so the feature will have to be completely rethought and redone to actually support this in v8.

As the feature is something we would only be able to provide to a subset of our users, it does not currently have priority for HQ. We are of course always open to a community PR on this, but due to the amount of work required and the very likely possibility of having to do it all over due to considerations that don't come up initially... I cannot really recommend anyone to actually start working on this.

@AndyButland

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

Do I have to hand my certificate back then (scroll to bottom)? :-)

@nul800sebastiaan

This comment has been minimized.

Copy link
Member

commented May 3, 2019

@AndyButland It would definitely be something to consider re-instating that award for in the next year ;-)

As Claus mentioned, we won't put the work in right now, but we're open for incoming PRs!
I've marked this as "Up for grabs" so that you or someone else coming along could create a pull request for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.