Tickets :: [#11187] Add an undelete feature for Kronolith Events

6.0.0-alpha10

5/14/25

Search Results: 374 of 573 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

Summary	Add an undelete feature for Kronolith Events
Queue	Kronolith
Queue Version	Git master
Type	Enhancement
State	Accepted
Priority	1. Low
Owners
Requester	ralf.lang (at) ralf-lang (dot) de
Created	05/10/2012 (4752 days ago)
Due
Updated	01/05/2017 (3051 days ago)
Assigned
Resolved
Milestone
Patch	No

01/05/2017 08:13:11 PM	Jan Schneider	Comment #6	Reply to this comment
See https://wiki.horde.org/Project/Undo

01/28/2016 04:41:02 PM	Jan Schneider	State ⇒ Accepted Version ⇒ Git master

06/01/2012 03:59:50 PM	Ralf Lang	Comment #5	Reply to this comment
[Show Quoted Text - 9 lines][Hide Quoted Text] * 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 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. 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.

06/01/2012 03:56:35 PM	Jan Schneider	Comment #4	Reply to this comment
[Show Quoted Text - 38 lines][Hide Quoted Text] 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. 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 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

06/01/2012 03:42:46 PM	Ralf Lang	Comment #3	Reply to this comment
[Show Quoted Text - 27 lines][Hide Quoted Text] 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. 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

05/15/2012 05:13:02 PM	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.

05/10/2012 09:07:18 AM	Ralf Lang	Comment #1 Priority ⇒ 1. Low Type ⇒ Enhancement Summary ⇒ Add an undelete feature for Kronolith Events Queue ⇒ Kronolith Milestone ⇒ Patch ⇒ No State ⇒ New	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?