6.0.0-git
2019-08-24

[#11187] Add an undelete feature for Kronolith Events
Summary Add an undelete feature for Kronolith Events
Queue Kronolith
Queue Version Git master
Type Enhancement
State Accepted
Priority 1. Low
Owners
Requester lang (at) b1-systems (dot) de
Created 2012-05-10 (2662 days ago)
Due
Updated 2017-01-05 (961 days ago)
Assigned
Resolved
Milestone
Patch No

History
2016-01-28 16:41:02 Jan Schneider State ⇒ Accepted
Version ⇒ Git master
 
2012-06-01 15:59:50 Ralf Lang (B1 Systems GmbH) Comment #5 Reply to this comment

[Show Quoted Text - 9 lines]
That's what I mean. If it's not working (no History backend) it should 
not break the calendar but fall back to what we have now.
2012-06-01 15:56:35 Jan Schneider Comment #4 Reply to this comment

[Show Quoted Text - 38 lines]
I don't see a good reason why we should make this configurable. If the 
history backend is available, we should support undelete. Unless 
someone comes up with a really good reason to separate one from the 
other.
* A deleted event should disappear from backend, reviving should add 
a new version of the old data
* We don't care about external clients. If horde is in the backend 
chain, we will be able to save undelete data. Undeleting can only be 
done through horde ui
2012-06-01 15:42:46 Ralf Lang (B1 Systems GmbH) Comment #3 Reply to this comment

[Show Quoted Text - 27 lines]
I've been thinking a while about this and I mostly agree.

* Histories is a sufficient undelete store - we already track deleting 
there for sync purposes and I could expand/modify the work on 
remembering attributes on change. This allows a backend-agnostic 
implementation.
* We currently only have sql as a history backend but probably indexed 
key stores or nosql dbs like couch or mongo could be added if somebody 
needs/pays for this.
* Undelete/Roll Back/Revive should probably be optional
* A deleted event should disappear from backend, reviving should add a 
new version of the old data
* We don't care about external clients. If horde is in the backend 
chain, we will be able to save undelete data. Undeleting can only be 
done through horde ui
2012-05-15 17:13:02 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Should undeleting be implemented driver-agnostic (through added 
details in the horde_histories delete action or through a specific 
undo table) or should it make use of backend specific features and 
only be implemented for certain backends?
Good question. It would probably be easiest to implement on the driver 
level, because it would only require adding a flag, and we won't take 
the risk of losing any event information.
This could be tough or even impossible with some drivers though.
A driver-agnostic solution would make this work in all drivers, though 
it still won't work if using a shared backend with different clients. 
OTOH those other clients wouldn't recognize the custom backend flag 
anyway, so this probably shouldn't count as an argument. And we 
probably *do* want those events to disappear for other clients, even 
if we allow undo.

Since the reason for using a different backend than SQL might be to 
not rely on an SQL server, those events shouldn't go into a separate 
table. Pondering all arguments, I think storing them in the history 
backend could be the best solution. This would also allow this to be 
implemented easily for other applications too.
How should undelete deal with the sync-relevant history entries?
For synchronization (or any other external client for that matter), 
this would be a regular deletion. Undeleting would not be reversing 
the deletion, but re-adding the deleted event.
2012-05-10 09:07:18 Ralf Lang (B1 Systems GmbH) Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Add an undelete feature for Kronolith Events
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
Users accidentally delete events, at times even through remote 
interfaces we cannot completely control.

There should be a feature to track and undo recent delete event 
actions for future versions.
We already track the delete event for syncing purposes.

Should undeleting be implemented driver-agnostic (through added 
details in the horde_histories delete action or through a specific 
undo table) or should it make use of backend specific features and 
only be implemented for certain backends?

How should undelete deal with the sync-relevant history entries?

Saved Queries