We have moved to GitHub Issues
Created by Pete Duncanson 21 Dec 2015, 16:59:14 Updated by Shannon Deminick 11 Jan 2016, 16:15:23
Interesting gotcha raised by Mark Goodson.
Short version: if you remove a composite from a doctype that it is already applied on it should give you a warning that any data in those fields will be "lost" and "are you sure". The data I believe is actually still there in the database but won't show up in the doctype anymore, I imagine that re-adding the composite to the doctype might even bring the data back but don't hold me to that!
"Basically if I have used a composition on a doc type; ie a ContentComposition that has Title, RichTextArea, and used this across all my document types, and content is imported; and later on I need to add a Summary Text Box to only on one document type, maybe an article, but here is the thing the new Summary needs to be inbetween Title and Rich Text Area, you know because it's better for the editors not to have Title - RichText - Summary;
(well (and I know nested doc types doesn't solve this problem either, it's where both approaches fall down, and it's a niche issue, but once a build...))
...well, the great flexible thing about Compositions is I can create a new composition with the right order, Title - Summary - RichTextArea, and call it my ArticleContentComposition; and Title and RichTextArea 'can have the same' property names and alias as the Title and RichTextArea on my original ContentComposition, so no changes to my templates - awesome it's the obvious thing to do - and I can go to my DocType untick the ContentComposition, and Tick ArticleContentComposition instead, however even though those DocType properties of Title and RichTextArea are called the same thing Alias wise, they are not the actual same property, and entered data into those fields just vanish, just sorta accidentally, the rigidity of nested doctypes prevents you from making this error..."
Removing a composition ''does'' delete all the associated property data and ''yes'' there should be a huge warning saying, ''there is no way back, are you sure?''. The data is gone, removed, not in the database anymore. I am adding this as a task for 7.4 as I ''do'' think that many ppl will shoot themselves in the foot, eg uncheck a composition by accident and check it back and assume that the data is still there: no, it's all gone, better have a backup.
As for the detailed scenario you describe... it cannot simply work like that. Property data is linked to a property type, not a property alias (because the alias of that type may change). Removing a property (via unchecking a composition) and adding another property with the same alias (via checking another composition) is ''not'' "adding that property again" - it's adding another different property. It's an interesting scenario though, but part of a more global work on "content type maintenant" (what-if I want to migrate a property from a content type to a composition, these sorts of things).
@zpqrtbnk yes it can't work like that but when you work with compositions, it leads you to think a bit like that, it is the paradigm shift between nested doc types and compositions; you can't un-tick a parent doc type :-)... the flexibility of compositions is what allows people to trip themselves up so big +1 for the warning... The need for which highlights that the two approaches aren't 100% the same, 98% though.
@zpqrtbnk this was what my DocTypeExtensions package was meant to be a long time ago to give you the ability to refactor your doc types by extracting master doc types (comps now), and switching doc types etc. I think this is quite an important feature for those who maintain sites as changes are inevitable and what was a perfect solution to start with, might not fit with the required changes so the ability to refactor your doc types like this would be a huge help.
@matt I am 200% behind you on that one. Would LOVE to be able to manage change for content types: merge types, move properties, etc. As in many cases I usually get things wrong the first time. What's the status of that package?
We have extended the overlay directive so it's possible to add a confirmation prompt when submitting the overlay. It is now possible to extend the overlay model with an confirmSubmit object with details for the prompt: title, description, checkboxLabel, enable and show. We use this new way to show the confirmation for composition.
How to test:
Tested, all seems to work for me! Just gonna cause some nasty merge conflicts :P all good, i'll sort it out.
Backwards Compatible: True
Due in version: 7.4.0
Sprint: Sprint 6