# Bulk actions confusion - Delete Topics
**URL:** https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444
**Category:** UX
**Tags:** search, bulk-actions
**Created:** [19 augustus 2026 om 13:02 UTC](https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444 "2026-08-19T13:02:45Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [21 augustus 2026 om 07:17 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.
---
_[View the full topic](https://meta.discourse.org/t/bulk-actions-confusion-delete-topics/410444)._