Repository navigation
Mass deletion of chat conversations #639
Description
Describe the feature you'd like to request
It would be nice to be able to delete multiple chat conversations. The user would be able to select some conversations and delete them all at once.
Describe the solution you'd like
- One additional endpoint that takes a list of session IDs (conversation IDs) and deletes them all, just like the "single deletion" endpoint does.
- A UI element to enter the deletion mode
- The conversation list items (left sidebar) can be selected in deletion mode
- Optional: Allow to "select all/none"
Describe alternatives you've considered
To save space in the UI, instead of an additional "delete multiple" button to enter deletion mode, there could be 2 context menu actions for each conversation list item:
- The existing "delete" that just deletes this conversation
- A "delete multiple" that enters deletion mode and selects this item
Activity
WSHAPER commentedon Sep 4, 2026
Implementation: https://github.com/WSHAPER/assistant/tree/feat/mass-delete-conversations (commit WSHAPER@f17c20fc) — PR to follow.
Testing notes for the mass-deletion implementation
While implementing this I drove the checks below with throwaway scripts (curl + headless Chromium). If someone wants to turn them into automated tests, see the last section.
API edge cases (both routes:
DELETE /ocs/v2.php/apps/assistant/chat/sessions?sessionIds[]=…and legacy/chat/delete_sessions):sessionIds=123→ 400 (param binding rejects it)/chat/sessions/{id},/chat/delete_session) unchanged/regression-checkedUI edge cases (conversation list, deletion mode):
:openbinding onNcDialoggets stuck here because the dialog's internal teardown is delayed by 300 ms; the fix bindsv-model:opento a writable computed and re-keys the dialog per open. This is the least obvious failure mode, and it needs a page reload to recover if regressedLocal-env gotchas when testing with Ollama + a qwen3.x model (may explain flaky generation unrelated to this feature):
integration_openai's defaultmax_tokens=1000is exhausted by the model's thinking before any content; long thinking also occasionally returns an emptycontentwith the answer only in reasoning (integration_openai reports "No result in OpenAI/LocalAI response"). Raisingmax_tokensand appending/no_thinkto the chat instructions works around both. Also,occ taskprocessing:worker -t 60kills in-flight generations on slow CPU inference.Frontend test setup: this repo currently has no JS test infrastructure at all (only phpunit). The edge cases above would map to Vitest component tests + Playwright e2e, as recently scaffolded in nextcloud/circles#2562; server's
tests/playwright/could serve e2e once assistant is installable there. Worth a dedicated ticket if there's interest — happy to open one.julien-nc commentedon Sep 8, 2026
Hey, thank you for the changes and the details. This looks good and works fine.
For later, when this will be a PR:
WSHAPER commentedon Sep 8, 2026
Thanks for checking! Both things are done now, the branch is updated (WSHAPER/assistant@feat/mass-delete-conversations,
69b474ab).About the menu in the viewer: I had a look and the container of that NcActions popover is hardcoded to
#app-navigation-vueinside NcAppNavigationItem. I checked the version we use (9.9.0), the latest release and current master of nextcloud-vue, it's the same everywhere, so bumping the dependency won't change anything. There is no prop for it right now. When the assistant opens on top of the viewer there are two of those elements in the page and floating-vue resolves the selector with document.querySelector, so the popover gets attached to the one from Files underneath the viewer and opens out of sight. Your hunch about the mountpoint was right. NcActions itself already has a container prop, so upstream it would just be a matter of forwarding something like that from NcAppNavigationItem. I can open an issue there if that helps.On the inline action plus menu item combo, I agree it looked off. Went with your last suggestion and removed the per item multi delete action since the global button at the top covers it. Single delete is the only action left and it's always inline now, so there's no menu at all anymore, which also makes the viewer problem go away for this feature.
WSHAPER commentedon Oct 5, 2026
Follow-up from the review call with @julien-nc (2026-10-05): the implementation is otherwise ready, the one open point is the placement of the delete button.
Right now the button is quite prominent in the conversation list. Deleting conversations is a rare action, so it draws more space and attention than it deserves, and a design review would likely flag the same.
Proposal: move the delete control to the bottom of the conversation list so it is less invasive, then iterate on the exact placement later if needed.
julien-nc commentedon Oct 5, 2026
Can you create a PR in this repo? I'll review asap.
WSHAPER commentedon Oct 5, 2026
Update: after an audit I would lean towards keeping the sidebar-level delete button as is for now. The cleaner long-term home for bulk management is a dedicated conversation management view (grouped and sorted sidebar, management pane replacing the chat window), filed as #679. Implementation effort for list management should go there rather than into polishing the interim button placement, to avoid redundant work.
feat(chat): add mass deletion of conversations