When deleting a content type field, the UI shows the view as a dependency under configuration deletions and deletes the view when you confirm the delete.
In D7, the view gets automatically updated. (sort of, see #15). Users apparently do not expect this behavior and end up accidentally deleting a whole view. Possible user experience problems with this:
- The delete section is at the bottom of what is potentially a long list of updated configuration.
- Users get used to just confirming the less severe configuration entity updates and so are not aware they are deleting a whole view.
- Even if the user sees the message about deletion, there is no information on how to fix it instead.
The behavior itself should not be changed, but we can improve the user experience problem:
- Make deletions more obvious than automated dependency removals, possibly with a confirm form.
- Provide stronger/clearer warnings in the UI, e.g."Warning: You are about to delete an entire view".
- Provide instructions on what to do instead,e.g. "To remove this field without deleting these items, first edit the items so they no longer use this field."
Alternate resolution from #51 and onward:
The behaviour should be changed. By default, the View should just be disabled. An attempt can be made to update it by removing handlers that trigger the dependency, if this still leaves dependencies, disable the View so the user can manually update the View before enabling it again. This will prevent any unexpected data loss.
Things to look at (possibly in follow-ups):
Make sure the View gets deleted when the module providing the base table is uninstalled(fixed in #83)
- Add a check that a View is valid when enabling it.
- Add a fieldset to the confrm screen with all disabled config instead of putting it under 'updated' (follow up: )
Alternate resolution from #91 and onward:
The behaviour should be changed but only for field handlers. The proposed solution would be to remove any field handlers that have a dependency on any configuration being removed. If that solves all the dependencies then the View can just be updated and saved without this field. Dependencies because of other handlers (filters, relationships et al.) will still cause the whole View to be deleted. The removal of a field handler should have little impact on the overall working of the View, so the normal notice that it will be updated should suffice for that.
The deletion of a View because of a field handler is probably the most commonly occurring situation and the one where removing the handler should not have any dramatic effects.
Follow ups will be opened to see how we can handle the other types of handlers on a handler-type basis.
Decide on a proposed resolution. Needs designs and usability review for them once proposed.
User interface changes
Original report by [username]
I created a 'date' field on a content type and a view to for this content type.
Then i deleted the 'date' field from the content type and the whole view got deleted also without any warnings.