mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 02:48:13 -05:00
[GH-ISSUE #11741] feat: ability to recover deleted chats as admins #16340
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#16340
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jiajunly on GitHub (Mar 16, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/11741
Check Existing Issues
Problem Description
Some users may want to recover a conversation after deleting it, but once it's deleted, it no longer exists in the database.
Desired Solution you'd like
Add a global setting, "Recoverable after deletion." When this setting is enabled, the deletion becomes a soft delete. Add a
deleted_atfield in thechatstable, allowing users to delete conversations. After deletion, the conversation will no longer be visible to the user, but it will remain visible to administrators and can be recovered or deleted.Alternatives Considered
Thanks very much!
Additional Context
No response
@Classic298 commented on GitHub (Mar 16, 2025):
Add another idea to this feature request:
add a trash where deleted conversations go to
@jiajunly commented on GitHub (Mar 16, 2025):
Yes! This is indeed useful, but in fact, the trash function has already been implemented through the new conversation folder feature. At least, that's how we've been using it.
@taylorwilsdon commented on GitHub (Mar 17, 2025):
This strikes me as a user behavior / education opportunity rather than a code change, because Open-WebUI already has the
Archivefeature right aboveDelete- which is a soft delete that can be recovered or fully purged. You can already do exactly what you're describing today while still retaining the ability to actually delete chats, which many want (myself included).Just my 2c, but delete should delete, I would be unhappy if I found out that my database continued to grow more and more bloated even though I thought I was deleting messages after mass import events that needed cleanup etc. Delete already has an "are you sure" confirmation so it's not like it's happening accidentally, and in the event someone important regrets their decision restoring it from a prior database snapshot would be the next step in my playbook.
@tjbck commented on GitHub (Mar 19, 2025):
@taylorwilsdon agreed.