# Bulk actions confusion - Delete Topics
**URL:** https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444
**Category:** UX
**Tags:** search, bulk-actions
**Created:** [August 19, 2026, 1:02pm UTC](https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444 "2026-08-19T13:02:45Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 19, 2026, 1:02pm UTC](https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444/1 "2026-08-19T13:02:45Z")
I noticed in the bulk actions menu (visible on the search page, using bulk select for 1 or more posts).
There are two delete options:
Delete Topic(s)
Delete Post(s)
The confirmation for Delete Posts seems clear, but the confirmation for Delete Topics is confusing imo.
> **Permanently delete** the selected topics. This action cannot be undone.
from: `js.topic_bulk_actions.delete_topics.description`
If I confirm to delete the selected topic(s), they are deleted normally (soft) and can be restored.
This is with site setting `can_permanently_delete` as false (default).
Also, there doesn’t seem to be a visual distinction between search results that are a topic or a post/reply, besides hovering over them and looking at the end of the url. Which makes using these two bulk delete options a bit unintuitive for moderators imo.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [August 21, 2026, 7:17am UTC](https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444/3 "2026-08-21T07:17:37Z")
we’re in the process of improving the “actions” offered in bulk mode, but this one fell through the cracks as it’s not (_yet_) available.
>
>
> Reported in \[Bulk actions confusion - Delete Topics\](https://meta.discourse.org/…t/410444).
>
> Selecting topics and choosing \*\*Delete\*\* asks you to confirm:
>
> \> Permanently delete the selected topics. This action cannot be undone.
>
> …and then soft deletes them, so they can be recovered. Not search-specific — the same modal is used by every topic list.
>
> There is no configuration where the copy is true. \`TopicsBulkAction#delete\` builds \`PostDestroyer\` with an empty options hash, so \`permanent?\` is never satisfied, and \`PUT /topics/bulk\` doesn't permit \`force\_destroy\` in the first place. \`can\_permanently\_delete\` has no bearing on this path. The description was added with the copy pass in 4b6169028f and never matched the behaviour.
>
> \### Also fixed
>
> Two long-standing bugs in the same six lines:
>
> \- \`delete\` was the only operation in \`TopicsBulkAction\` that never appended to \`@changed\_ids\`, so the endpoint always answered \`{"topic\_ids":\[\]}\`. A bulk delete where the guardian skipped every topic looked exactly like a successful one, toast included.
>
> \- \`ordered\_posts\` is scoped by \`Trashable\`, so for a topic whose first post was already deleted it returned post 2. \`is\_first\_post?\` was then false, \`@topic.trash!\` never ran, and an unrelated reply was deleted while the topic stayed alive — reported as a success. \`TopicsController#destroy\` already gets this right with \`ordered\_posts.with\_deleted.first\`.
>
> \### Follow-ups, not in this PR
>
> \- \`ordered\_posts.first\` feeding \`PostDestroyer\` carries the same latent bug at five other call sites: \`Jobs::DeleteTopic\`, three in \`DestroyTask\`, and \`TopicGuardian#can\_recover\_topic?\`. Worth a \`Topic\` accessor rather than a sixth hand-rolled copy.
> \- Search results give no hint whether a hit is a topic or a reply, which is the other half of the report. \`post\_number\` is already serialized and \`search.post\_format\` already exists, but is gated to the in-topic dropdown.
> \- Translations of this key still assert permanence until the pipeline catches up.