We're developing a plugin for some web-based application. Our plugin somehow enrich the functionality of the hosted application and uses some of the provided UI for certain functionality like adding new issues (the hosting application is a bug-tracking system), etc.
At the moment we're figuring out how to implement multi-step undo (redo) within our plugin (which has it's own UI embedded into hosted app's UI). Everything looks pretty good for actions which are our own (and doesn't require any hosted app UI calls), but things become unclear in situations when user performs actions based on UI provided by the outer app. Specifically, some of the actions could not be undone in this case.
We've discussed several possible solutions, but every has it's own drawbacks:
Simply ignore such actions (i.e. skip) and let user undo undoable actions only. This behaviour is bad because throwing out some steps silently (or even with the confirmation) will lead to the inconsistent state at the end of the undo: some things will be undone and other will not. Confirmations will help a bit (users will be aware of what's happened), but system will be at inconsistent state at the end anyway.
Reset the undo history at every non-undoable action (i.e. it will not be possible to undo further). The problem here is that this behaviour will confuse users too since there is no clear way to know which actions will reset the undo history.
Do not provide undo for all of the available actions even in our own plugin, but make it available only for really harmful actions (like bulk remove, etc), which could happen accidentally, etc. This solution will be less powerful but seems to be more clear (we'll show the message every time undo will be available and, possibly, doesn't allow multi-step undo at all).
So, how do you think, which solution are more user-friendly?