Je l’ai constaté dans le menu des actions groupées (visible sur la page de recherche, en utilisant la sélection groupée pour un ou plusieurs messages).
Il y a deux options de suppression :
La confirmation pour « Supprimer les messages » semble claire, mais celle pour « Supprimer les sujets » est, à mon avis, confuse.
Supprimer définitivement les sujets sélectionnés. Cette action est irréversible.
issu de : js.topic_bulk_actions.delete_topics.description
Si je confirme la suppression du ou des sujets sélectionnés, ils sont supprimés normalement (suppression douce) et peuvent être restaurés.
Cela se produit alors que le paramètre du site can_permanently_delete est défini sur false (valeur par défaut).
De plus, il ne semble pas y avoir de distinction visuelle entre les résultats de recherche qui sont des sujets et ceux qui sont des messages/réponses, à part en survolant les éléments et en regardant la fin de l’URL. Cela rend l’utilisation de ces deux options de suppression groupée un peu contre-intuitive pour les modérateurs, à mon avis.
3 « J'aime »
zogstrip
Août 21, 2026, 7:17
3
nous sommes en train d’améliorer les « actions » proposées en mode par lot, mais celle-ci a été oubliée car elle n’est pas (encore
main ← fix-bulk-delete-topics-copy
merged 07:46AM - 25 Aug 26 UTC
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.
3 « J'aime »
