With the possibly upcoming Trash feature, we need to decide what should be done when a data API call deletes a note. Currently it permanently deletes the note, and I'm thinking about making it delete it to the trash instead (it seems safer), unless a parameter such as permanent=1 is specified.
This is however a breaking change since previously the note would be permanently deleted, and I'm wondering whether it matters or not. So if you are using the data API either in an application or a plugin, please could you let me know your thoughts?
So the two options would be:
Delete to trash by default
The note is moved to trash and can be restored. To delete a note permanently, call:
DELETE /notes/:id?permanent=1
Advantage: safer - the user can recover the note if it was accidentally deleted
Disadvantage: breaking change - plugins or apps that expect the note to be gone for good may have to be updated
Delete permanently by default
The note permanently deleted and cannot be restored. To delete a note to the trash instead, call:
DELETE /notes/:id?to_trash=1
Advantage: Works like before, no breaking change.
Disadvantage: More dangerous. By default, there's no way to recover the note.
On the joplin subreddit, I have seen so many posts about people losing notes or losing the entire database, and this turns them off the app, and may turn prospective users off as well. Yes, there is typically user error involved, but in general, it's a lot easier to lose data in Joplin than it is in Evernote.
As Joplin moves from being a note app for bleeding edge technically inclined users (i.e., more like the users here who are developing plugins, modifying CSS, etc.) to more mainstream note users (i.e., more like users on reddit and even less tech savvy users), I'd urge the devs to err on the side of making it harder to inadvertently lose data.
Unfortunately this feature will not solve users making configuration mistakes. The comparison to Evernote is not really accurate because for Joplin the user controls both the client and the server, so indeed there are ways to make mistakes and wipe out all the notes.
A better comparison would probably be Joplin + Joplin Cloud because in this case it's not possible to play with the sync target config, and thus cases where the user loses all their notes are very rare (in fact I can't remember it ever happened).
(On the other hand I keep being asked to add a feature to delete all the notes on Joplin Cloud, and you can understand why I'm not keen on adding this)
I think it makes a lot of sense to put this in as default to the data API - at least when considering its more "direct" usage which can be scripted or used in external applications. I'm not sure if there are examples of issues but I think the potential benefits are significant. Joplin attracts a wide spectrum of "tech-savvy-ness" and there are a few instances where people are running various scripts or apps from the forum that have caused problems or have the potential to cause significant data loss.
For example I could write a badly thought out shell script that uses the data API to make mass deletions of notes with specific critera. It might be fine for my use case and shared on the forums but could make some dangerous assumptions relating to my notes and use of Joplin. Some unsuspecting person could use that script and cause massive damage to their data even if following all the correct instructions - both people are operating in good faith and did nothing "wrong" but it has still caused damage. Yes that person should have backed up their data before running some weird script from the internet but that may only be obvious to those aware of how Joplin works on a bit more of the "tech-savvy" side. For one used to Evernote this operation and potential damage just isn't possible.
So long as it is easy to act in the "old/legacy mode" via a simple extra parameter or something I don't think it should be too much effort for any current maintainers of scripts/apps to amend their code to gain legacy behaviour back. I think the benefits of making data "safer" by default is far more beneficial as a whole.
Yes, and I have pointed this out on reddit, namely that when Evernote or some other corporation controls the cloud sync target, there is less opportunity for the user to screw things up.
I just think that in general, the app should be designed to make it harder to lose data. In the case of self-directed cloud sync, maybe there should be clearer directions (even on this forum, let alone reddit, we routinely see people asking questions about changing sync targets, and that's partly because there just isn't enough clear documentation on managing self-directed sync), more warnings, etc. But that's beyond the scope of this thread. Just wanted to point out that people are losing their data, and they aren't thinking through the nuances of self-directed cloud sync vs corporate cloud sync, they are upset that they lost their data, and this never happened to them on Evernote/other corporate cloud note app, and thus they blame it on Joplin and move on to another app.
Don't get me wrong, I am a Joplin evangelist, and I think the app is moving in the right direction toward data safety (e.g., incorporating Simple Backup into the core). Just wanted to report what I'm seeing on the 'frontlines' so to speak, as Joplin usage moves to the mainstream note app user community.
Rather than think of it as "current default behaviour," I'd recommend thinking of it in terms of the current app being broken when it comes to the deletion policy. No offense. But I can't think of any comparable platform that will delete things permanently as the default behaviour. So if there was ever going to be a so called "breaking change," then I think it should be for fixing something that was already broken, imo.
In other words, I think the new default behaviour should be to have notes go to the trash.
additionally, although you didn't ask…
If the new delete interface (assuming there will be one) could have an option to click for "Delete permanently with no way to recover" that might be a kindness for those one or two () individuals who actually liked the current behaviour.
Or maybe if shift + del could be to permanently delete (with that warning above) that might also be good.
Thanks so much for working on this! Personally I don't delete notes very often, although I might get in the habit once this is changed.
I would really appreciate if ... if there must be a trashcan ... the user could turn it completely off in settings. Look into the trashcan of most computers, after a few months it is filled with files and folders, and nobody has the time and energy to decide case by case what to restore and what to -- finally -- delete.
Is the trash can just a notebook? Will it just be moved to this notebook when a note is deleted? Is there any link to an explanation or instructions, I haven't been paying too much attention to what's going on in the forums lately, maybe this affects the implementation of vscode plugin.
I mean, if you haven't missed it in a couple of months, it's ready to be deleted without further decisions, eh?
I don't think the idea of a trashcan is to have a staging area for things to be processed later. It's just to prevent the accidental permanant deletion of something that you would rather not. The trash cans I am familiar with (both literal and digital) just get emptied on a regular schedule automatically. I had assumed that this would be part of the new Joplin trashcan.
Yes this will be included. And it will be possible to set for how long you want to keep your data. So if you don't really want to use the trash you can set it to 24h for example.
But technically, a deleted note will simply have a deleted_time property set to non-zero. Then the trash will be a virtual folder that will list these notes.
I don't think it will affect the VSCode plugin - you would still call DELETE /notes/:id and that will set the deleted_time property, essentially moving the note the trash. If you have a requirement to permanently delete the note though, you would have to change your plugin to provide the permanent=1 parameter (since it looks like this is what we're going to do).
For existing api consumers it might be an annoyance (the trash will be quickly filled with notes), but doesn't materially change anything else. The note history feature already means that a lot of deletes don't exactly free up space on the HDD anyway.
For new api consumers, they might not read the api docs closely and assume delete is the same as the app. This could lead to notes being lost .
That said, I'm not a consumer of the delete endpoint, so take my opinion with a grain of salt.
For "normal" notes, I would prefer a delete by moving notes to the trash bin (as a Joplin folder) with a configurable retention period. A nice-to-have for users would be to be able to change the setting for specific folders from the default (trash bin) to permanent delete.
But this trash bin behavior should not be used for those dummy files that are used to prevent concurrent syncs.
I've had sync problems in the past where the root cause was that the cloud drive that I used put every deleted file in a trash bin (including these sync prevention files) and where the trash bin was limited to a certain number of files. For normal usage that was not a problem, because it's rather untypical to delete masses of files a day manually. But with a 5 minutes interval to check for note updates and multiple devices the syncs filled the trash bin quickly and syncs failed permanently, because the technical files for indicating a current sync were not deleted anymore. As there was no way to change the behavior of the cloud drive, I had to switch to a different provider.
Joplin doesn't use physical files to store data so those files would never be part of this. Revisions are already stored in the database, essentially what is being proposed is to make those revisions that belong to otherwise deleted notes, visible in the UI.
) individuals who actually liked the current behaviour.