Right now there is no way to undo changes to periods which are committed to storage.
I suggest having the backend keep some copies of each period as it is modified. For example:
Simply keep a rolling window of the last, say, 10 versions
Or something smarter, like up to 10 versions from the last day then up to 1 version per day for the last 30 days
Another idea would be to take into account the "size" of the change, making sure that the last version before a "large" change is always preserved.
This would not only allow an undo feature to be built, that would be convenient for a user if they make some change by mistake, but it could also be an important safeguard against UI bugs. For example, if a bug caused the UI to remove or corrupt a large number of objectives, it would still be possible to recover the data.
An actual undo feature would require backups to be exposed via the web API, and a UI feature built to browse and restore them, but the UI bug safeguard would just require the copies to exist in the backend, so they could be restored by an administrator, e.g. through the Google Cloud Datastore web UI.
Right now there is no way to undo changes to periods which are committed to storage.
I suggest having the backend keep some copies of each period as it is modified. For example:
This would not only allow an undo feature to be built, that would be convenient for a user if they make some change by mistake, but it could also be an important safeguard against UI bugs. For example, if a bug caused the UI to remove or corrupt a large number of objectives, it would still be possible to recover the data.
An actual undo feature would require backups to be exposed via the web API, and a UI feature built to browse and restore them, but the UI bug safeguard would just require the copies to exist in the backend, so they could be restored by an administrator, e.g. through the Google Cloud Datastore web UI.