I created a content type that has fields and parts. While playing around with the configuration, it occurred to me that it would be relatively easy to make a bad click and remove a part or a field. As the system stands now, someone could accidently
click 'remove' and not even realize they did it. There should be some form of yes/no confirmation on removal (a little java script in the base?).
I decided to see how the system responded in the case of 'accidental' removal. I added a field to a 'user' content type, added some data via a user, then deleted the field from the content type. I found if I recreated the field with the same
name, it reconnects to the previous data. So it is possible to recover the information, but that requires the user to remember the field name (and possibly its settings). I'm not sure if that is by design or a side affect of the particular field.
So that got me thinking about a part of the system that I don't understand well.. the nitty gritty of data management. When a field is written should/can it delete its data when removed? If the general design is to leave the data orphaned how
does it eventually get purged?
I had a premature idea, since I don't know the answer to the above questions, but why not include a disable option with fields/parts of the content items. Let the admin see disabled parts and fields in their view as an option. This would fill
a lot of generic user scenarios like temporarily disabling some feature, taking something offline to administrate, give time to consider/view tentative changes or simply storing old information. Then that leaves 'removal' as permanent deletion option
that also purges the data. This would create a work flow that moves from active to disabled to permanently deleted.
I'll add an issue about the lack of confirmation (I don't see it). As for the idea of 'disabled' I'm hoping to learn if there is already some established manner for handling data as well as throwing out the idea for discussion.