Add support for trash

[laurent22]

Fourth (known) attempt to add a trash folder. This time by adding the deleted_time property as discussed in this previous pull request: #483 (comment)

• One thing we'll have to clarify with plugin developers is what should happen when a note is deleted via the data API - by default should it be moved to the trash (breaking change) or permanently deleted (no breaking change)? In any case we will add an option so that optionally the note can be moved to the trash or not.

• Internally, notes are permanently deleted by default unless a toTrash option is set. This ensures that everything, and sync in particular, is unaffected by this change. Then we just need to set the toTrash property where user actions are involved such as when deleting from the note list.

• With this design the trash content will be synchronised like any other folder. This is probably desirable anyway because when a note is deleted we might not remember on which device it was done, and having the trash replicated would solve this.

Resolves #483

[tessus]

Is the trash folder automatically ignored during search?

[laurent22]

Yes, notes in the trash will be excluded from most places in the UI, including search, tags, GotoAnything and possibly the API (but we'll need to check what plugins are doing).

One issue with this PR is that an old version of the app will not handle the "deleted_time" property and thus will still display the notes, and probably even restore them if the user modifies them. Also I think it will restore them if the user sync, then upgrade the client.

It means before this feature we'll probably need to implement a way to tell a client that it needs to be upgraded before syncing with the server.

[tessus]

This sounds great.

It means before this feature we'll probably need to implement a way to tell a client that it needs to be upgraded before syncing with the server.

Haven't you already done that? Isn't that the sync version?

[laurent22]

Haven't you already done that? Isn't that the sync version?

The sync version is tell whether the sync target needs to be upgraded or not. Here it would be the opposite - it would tell whether the client needs to be upgraded or not.

And in fact, I just realised that if we do this it should be done a few versions before we release the trash feature, otherwise it's not going to help

[tomasz1986]

Would it be possible to have an option to automatically delete old notes? It could be a setting similar to the current "note history" (e.g. delete after 90 days, etc.). Having a trash is useful for safety purposes, but having to go through it and delete obsolete notes manually is not fun. Such automatic cleanup of trash folders is common in mail clients (both local and Web), and also Windows has it for the Recycle Bin (not sure about other operating systems).

[personalizedrefrigerator]

My understanding of this pull request is that, after connecting one 3.0 version client to the sync target, all other clients will have to be upgraded to version 3.0.

This could cause problems for users who prefer to use prerelease versions on desktop, but, for example, are unwilling to manually install the prerelease APK on mobile.

Would it be possible to change version 2.14 such that users can safely sync it with a version 3.0 sync target? (For example, make it ignore all items with a deleted_time property).

[laurent22]

Would it be possible to change version 2.14 such that users can safely sync it with a version 3.0 sync target? (For example, make it ignore all items with a deleted_time property).

The problem is that if someone sync with a older client, the deleted_time property will be gone and the deleted notes will reappear on that client. Then if they change that note, it will be undeleted from the new client too. This is not critical actually but it would be nice to avoid that confusion.

Maybe we shouldn't enforce client upgrade from the prerelease then? We just enable it when we do the final release.