일괄 작업 메뉴(검색 페이지에서 1개 이상의 게시물을 일괄 선택할 때 표시됨)에서 다음을 발견했습니다.
삭제 옵션이 두 가지 있습니다:
Delete Posts의 확인 메시지는 명확해 보이지만, Delete Topics의 확인 메시지는 제 생각에는 혼란스럽습니다.
선택된 주제(토론)를 영구적으로 삭제 합니다. 이 작업은 되돌릴 수 없습니다.
출처: js.topic_bulk_actions.delete_topics.description
선택된 주제(토론) 삭제를 확인하면 정상적으로(소프트) 삭제되고 복원할 수 있습니다.
이것은 사이트 설정 can_permanently_delete가 false(기본값)인 상태입니다.
또한, 검색 결과 중 어떤 것이 주제(topic)이고 어떤 것이 게시물/답글(post/reply)인지 구별하는 시각적 차이가 마우스를 올렸을 때 URL 끝부분을 확인하는 것 외에는 없어 보입니다. 이로 인해 이 두 가지 일괄 삭제 옵션을 사용하는 것이 제 생각에는 관리자(moderators)에게 직관적이지 않습니다.
3개의 좋아요
일괄 모드에서 제공하는 "액션"을 개선하는 작업을 진행 중이지만, 이 기능은 아직(아직) 사용할 수 없어 누락되었습니다.
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개의 좋아요
