Add recycle bin to Bookmarks UI to make restoring deleted bookmarks easier
Steps to reproduce
- Delete bookmark in Bookmarks app
Expected behaviour
Bookmarks should be put into a recycle bin for easy restoration or final deletion. This would prevent deleting bookmarks accidentally and users would be able to restore them easily. Also, a deletion from a client by accident would make restoration easier.
Actual behaviour
Bookmarks are deleted without the ability to restore them.
Hi @marcelklehr ,
I got hit by the lack of a way to undelete bookmarks after Floccus deleted half of my bookmarks due to syncing troubles.
Would you be ok with me having a stab at this? I've been tinkering with the Bookmarks app a bit already and got it to display a "Deleted bookmarks" menu entry similar to the Files app. I also managed to give bookmarks a "deleted" property.

Let me know!
@DeathByDenim That would be really cool! I think it would be useful to have a trash bin folder per user, similar to the way the root folders are currently organized. That way folder's could also be put into the trash bin and would retain their hierarchy. Bookmarks should still have a deleted property to avoid displaying them for searches or similar. And we'd need some kind of auto-cleaning of the trash-bin.
Sounds good. Forked and at work! I'll let you know if I run into any trouble.
Hi @marcelklehr ,
I've been making progress (slowly!). I've been modelling the behaviour of the trash on the Files application. It works now for bookmarks:
https://user-images.githubusercontent.com/5130183/104537475-09325800-55e8-11eb-959d-65b441052a4e.mp4
The trash folder is per user. Deleted bookmarks don't show up anywhere else, including searches, thanks to the new "deleted" property they now have.
Next up are folders. I was going to model that on the Files application again, which does not respect folder structure. Well, in displaying it anyway. When a file is deleted from a folder, it will appear in the root of the trash bin. When restoring, it will go back into the original folder (if it still exist, it not it goes to the root).
For consistency's sake, it would probably be good to go with the same behaviour, but I think it is different from what you described because some of the hierarchy would be lost unless the bookmark is restored. What is your opinion of this?
Thanks!
Awesome! I'm really excited about this :tada:
Next up are folders. I was going to model that on the Files application again, which does not respect folder structure. Well, in displaying it anyway. When a file is deleted from a folder, it will appear in the root of the trash bin. When restoring, it will go back into the original folder (if it still exist, it not it goes to the root).
I think that's a good idea. For folders, having a deleted attribute would make sense, too. Ideally, the trash bin would then only show individual bookmarks and folders that are not already contained in any other deleted folder. That will probably make it less performant as there's no fast way to find out about ancestors other then traversing the tree, but we can always add some caching later.
Well, just to let you know that this is still ongoing. Folders are a lot harder.
I can mark them as "deleted" just fine and they pop up in the "Deleted bookmarks" section, but displaying that correctly (and getting the counts right) is tricky. I'm experimenting with a new route now in src/routes.js for navigating deleted folders. We'll see how that goes.
I'm determined to get this working however!
@DeathByDenim If you like you can already submit a draft pull request while you work on this. I'd be happy to give pointers and feedback even if it's early :)
Oh, that would be great! I did not include my experiments with a new route in here since I'm not certain that's the way to go yet.