[GH-ISSUE #14761] feat: Add confirmation modal to delete shared link when archiving chat #17357

New Issue

GiteaMirror · 2026-04-19T23:05:31-05:00

GiteaMirror commented

2026-04-19 23:05:31 -05:00

Originally created by @silentoplayz on GitHub (Jun 7, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14761

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

Upon discovery, I've found that shared links for chats in Open WebUI continue functioning even after archiving the respective chat. This can lead to unintended exposure of chat content if a user expects archiving to also revoke shared access. Specifically, if a chat is shared and then archived, the shared chat URL remains active and viewable by anyone with the link. Furthermore, while the archived chat is hidden from the regular user's chat list, and also from the admin panel's user chat list, it can still be directly accessed and viewed by an administrator if they possess the shared URL. This creates a potential privacy and data control issue as the chat becomes 'hidden' but not truly 'inaccessible' via its shared link, making management of shared content after archiving unclear and difficult.

Desired Solution you'd like

To improve the user experience and control over shared chats, I propose the following:

A confirmation modal should appear when a user selects 'Archive' from a chat's three-dot menu.
This modal should only appear if there is an active shared link associated with that specific chat.
The modal should provide a clear option to either Keep or Delete the chat's existing share link before the actual archiving process occurs.

This way, users are given explicit control over the status of their shared links when they decide to archive a chat, ensuring data privacy and proper content management. It allows users who wish for the link to remain active to proceed, while also providing a clear pathway for those who intend to revoke access upon archiving.

Alternatives Considered

Currently, users would have to manually go into the shared link settings to revoke access before archiving, which is a less intuitive and potentially overlooked step.

One strong alternative considered was to implement automatic revocation of shared links when a chat is archived. This would simplify the process for users by ensuring that archiving inherently revokes public access, aligning with the common expectation that an archived item is no longer easily accessible. This approach offers maximum simplicity and privacy by default, as the user wouldn't need to take any extra steps. However, it removes the user's explicit control over whether a shared link should remain active post-archiving (though the current problem description suggests users generally don't want links to remain active).

Another alternative was to display a visual indicator (e.g., a 'share' icon) next to chats that have an active shared link, particularly within the 'Archived Chats' modal. While this would serve as a reminder that a shared link exists for an archived chat, it is less ideal than the proposed solution. It doesn't proactively prompt the user to manage the shared link at the critical moment of archiving. Users would still need to navigate to a separate section, identify the icon, and then take further action to delete the link, adding extra steps to a process that should be streamlined. This approach shifts the burden of remembering to manage shared links to after the archiving event, increasing the likelihood that links might remain active inadvertently.

The proposed solution (a confirmation modal with the option to delete the shared link at the point of archiving) is preferred as it strikes a balance between user control and a streamlined workflow. It proactively informs the user of an active shared link precisely when they are making a decision about the chat's status, allowing for immediate action without forcing automatic revocation or requiring a separate, less intuitive management step. It serves as a clear reminder to the end-user that they've generated a share link for their chat in the past, without them having to check the Share menu before archiving the chat.

Additional Context

This feature would enhance user control and privacy, aligning the archiving action with a more comprehensive management of chat-related data, including shared links. It addresses the current discrepancy where archiving removes the chat from views but not its shared public accessibility, even to administrators who might inadvertently access it via an old link. The goal is to provide explicit control at the point of action, catering to diverse user expectations regarding shared link validity.

Originally created by @silentoplayz on GitHub (Jun 7, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14761 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Upon discovery, I've found that shared links for chats in Open WebUI continue functioning even after archiving the respective chat. This can lead to unintended exposure of chat content if a user expects archiving to also revoke shared access. Specifically, if a chat is shared and then archived, the shared chat URL remains active and viewable by anyone with the link. Furthermore, while the archived chat is hidden from the regular user's chat list, and also from the admin panel's user chat list, it can still be directly accessed and viewed by an administrator if they possess the shared URL. This creates a potential privacy and data control issue as the chat becomes 'hidden' but not truly 'inaccessible' via its shared link, making management of shared content after archiving unclear and difficult. ### Desired Solution you'd like To improve the user experience and control over shared chats, I propose the following: 1. A confirmation modal should appear when a user selects 'Archive' from a chat's three-dot menu. 2. This modal should only appear if there is an active shared link associated with that specific chat. 3. The modal should provide a clear option to either `Keep` or `Delete` the chat's existing share link before the actual archiving process occurs. This way, users are given explicit control over the status of their shared links when they decide to archive a chat, ensuring data privacy and proper content management. It allows users who wish for the link to remain active to proceed, while also providing a clear pathway for those who intend to revoke access upon archiving. ### Alternatives Considered Currently, users would have to manually go into the shared link settings to revoke access before archiving, which is a less intuitive and potentially overlooked step. One strong alternative considered was to implement **automatic revocation of shared links when a chat is archived**. This would simplify the process for users by ensuring that archiving inherently revokes public access, aligning with the common expectation that an archived item is no longer easily accessible. This approach offers maximum simplicity and privacy by default, as the user wouldn't need to take any extra steps. However, it removes the user's explicit control over whether a shared link should remain active post-archiving (though the current problem description suggests users generally *don't* want links to remain active). Another alternative was to display a visual indicator (e.g., a 'share' icon) next to chats that have an active shared link, particularly within the 'Archived Chats' modal. While this would serve as a reminder that a shared link exists for an archived chat, it is less ideal than the proposed solution. It doesn't proactively prompt the user to manage the shared link at the critical moment of archiving. Users would still need to navigate to a separate section, identify the icon, and then take further action to delete the link, adding extra steps to a process that should be streamlined. This approach shifts the burden of remembering to manage shared links to after the archiving event, increasing the likelihood that links might remain active inadvertently. The proposed solution (a confirmation modal with the option to delete the shared link at the point of archiving) is preferred as it strikes a balance between user control and a streamlined workflow. It proactively informs the user of an active shared link precisely when they are making a decision about the chat's status, allowing for immediate action without forcing automatic revocation or requiring a separate, less intuitive management step. It serves as a clear reminder to the end-user that they've generated a share link for their chat in the past, without them having to check the Share menu before archiving the chat. ### Additional Context This feature would enhance user control and privacy, aligning the archiving action with a more comprehensive management of chat-related data, including shared links. It addresses the current discrepancy where archiving removes the chat from views but not its shared public accessibility, even to administrators who might inadvertently access it via an old link. The goal is to provide explicit control at the point of action, catering to diverse user expectations regarding shared link validity.

GiteaMirror added the enhancement label 2026-04-19 23:05:31 -05:00

GiteaMirror closed this issue

2026-04-19 23:05:31 -05:00

GiteaMirror referenced this issue

2026-04-20 00:27:28 -05:00

[GH-ISSUE #17357] issue: Dayjs does not localize according to selected language #18254

GiteaMirror referenced this issue

2026-04-25 07:40:00 -05:00

[GH-ISSUE #17357] issue: Dayjs does not localize according to selected language #33783

GiteaMirror referenced this issue

2026-05-05 20:14:09 -05:00

[GH-ISSUE #17357] issue: Dayjs does not localize according to selected language #56920