Items should be soft deleted and restoreable in case of things like accidental deletes.
GitHub issue: Have a "Trash" to keep (accidentally) deleted passwords · Issue #134 · bitwarden/server · GitHub
Items should be soft deleted and restoreable in case of things like accidental deletes.
GitHub issue: Have a "Trash" to keep (accidentally) deleted passwords · Issue #134 · bitwarden/server · GitHub
I would like to add few optionals or obvious requirements I would have as a user:
Please make this an option, and not a requirement.
Perhaps make “Trash” a special folder, like “No Folder?” Not sure if that would simplify implementation or complicate it.
Absolutely very important especially in a team.
I also support this suggestion
I agree, it’s a must-have feature
I would also suggest an “reminder” option for the administrator, that he can “confirm” the deletion.
Keen for a feature like this, especially if I could have infinite retention and use it as kind of holding ground for old logins that I don’t really need but might want to resurrect some day.
In the case of organization passwords maybe the recycle bin could be accessible only by admins of that organization?
This is high priority for us. Clicking the entry link in the event log entry: “Deleted item %entry-id%” currently takes the user to an empty search.
Agree, this is must have feature for teams.
I think soft deleted items should be searchable only from internal trash search, not at global search.
It is also very helpful when you accidental deleted an entry and can restore it from the trash (even after some days).
I see two use-cases for this feature (and I would use both). The first one is an archive functionality as described above. And the second one is soft delete. I have no problems if both cases are implemented in one feature.
I totally agree. Deleted (“archived”) items should not appear in the “normal” search. But they should still be searchable somehow.
Deletion: If you delete an entry, it should by default be moved into the trash and not actually deleted and auto-deletion after X days should be off by default. Since logins are typically plain text, there is no need to delete anything, storage-wise.
That said, you should be able to permanently delete an item if you delete it from trash. I’m thinking about dummy logins that you make for testing.
Any idea if this feature is being worked on and if so, does there happen to be a timeline on a release?
This is pretty crucial for premium users if they stored sites with TOTP. If I delete the entry and later need to log into that site I’m screwed. I can use a “forgot password” thingy for most situations unless 2-factor authenticators were saved in the vault.
Plus, it just seems easy to implement.
Add an is_deleted flag to every entry and default it to N.
Then, in the vault just show items with is_deleted = N
A trashcan folder would contain anything that has is_deleted = Y with an option to flip it back to N.
That’s how medical records systems handle deleting things because it’s crucial we don’t actually delete anything. Even if the software vendor has to troubleshoot your database, they’ll never delete. They may create a copy of a table as a backup and fix what they need to in the actual table. If I had something that did need changed for technical reasons they may set up the query for me but say it’s up to me to test and actually execute the change.
Additionally, given the tiny size of this sort of data and its value, I wouldn’t design a user vault to hard delete anything until someone deletes their account.
We are planning on moving our company to Bitwarden and not having a trash for deleted items is one of the main pain-points, so: is there any ETA for this?
Besides that, it would also be really great to have a «trash» in Organizations, so that only Admins & Owners, for example, could delete items from.
Thanks!
My company would also love to see this feature - any feedback on this? Is this in development? Thank you!
I totally agree with @eucalypto
There is a pretty big difference between archival and deletion.
They could be implemented in a similar fashion, but semantically they mean very different things, and combining them into one feature could have unexpected consequences, both for UX and for general integrity.
For example, systems that have a trash feature inevitably also have an “empty trash” feature to easily and quickly clear them permanently. I see no reason why this wouldn’t be added here as well. But if I “delete” an item in order to archive it, I (or someone else with adequate permissions) could accidentally empty the trash without realizing that it was holding at least some items just to keep them from being searched.
Also, if I archive an item and then later delete it from the archive, I’d expect the item to be moved to the trash just like every other non-deleted item. Maybe I deleted the item from the archive by mistake…
So there are quite a few use cases that indicate that these should be separate features. The only two things I can think of that they share is that items in an archive or in a trash should be hidden from search (or even just the regular list of items) unless they’re explicitly being looked up, and that they should continue to respect their original permissions from before they were archived or trashed.
Both features make a lot of sense, though I personally came here looking for an archival feature. Whatever the case, it’s really important in my opinion that they be kept separate.