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

Search Results: 64 of 94 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: .__ .___.. .. . [ __ _/ \ /\| \| [_././__. \/ \|___\__\|
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.
Attachment
Watch this ticket

Saved Queries