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

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/11187
------------------------------------------------------------------------------
  Ticket             | 11187
  Updated By         | Jan Schneider <jan at horde.org>
  Summary            | Add an undelete feature for Kronolith Events
  Queue              | Kronolith
  Version            | Git develop
  Type               | Enhancement
-State              | New
+State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2012-05-15 19:13) wrote:

> 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.