Desdenova wrote:The largest issue is that of designing an implementing an "undo" for certain things. If you were to delete a topic, it should use a confirmation and not an undo as otherwise you have to temporarily store that data somewhere while you make it possible to undo the action -- which means most likely that SQL would need to be stored. And that, itself, would be a headache with security.
For things like moving posts, I can see that being a good option, but not for something like deleting a post or a topic.
basically what you say is that for some operation, implementing "undo" is more difficult than others.
i think it is hard to argue against this - it is almost "self evident".
however, if the following route is taken:
-- try to come up with some "undo" mechanism, and try to make it as generic as possible.
-- begin implementing individual "undo" for more and more specific actions, using the generic infrastructure whenever possible
-- while doing so, whenever difficulties are encountered, always prefer to teach the generic mechanism to handle "yet another type of action" over solving one individual case.
-- every operation that gains an "undo" immediately loses the "are you sure".
hopefully, eventually we will get to a state where the "are you sure"s will be so rare that the operator *will* pay attention when she sees one.
specifically, i do not think that "delete" is an especially hard one to teach undo.
of course, there are *some* operations where "undo" just does not make sense: e.g., when you prune posts in order to reduce DB size, enabling "undo" will negate the objective of the action.
in those cases, maybe instead of "are you sure" a more specific "did you backup" (or whatever fits the case) should be used.
taken to the extreme, the undoable action can just be refused unless a recent enough backup was performed.