# 将“允许组删除所有帖子和主题”拆分为自有内容和全局内容权限

**URL:** <https://meta.discourse.org/t/split-delete-all-posts-and-topics-allowed-groups-into-own-content-and-global-content-permissions/403671>\
**Category:** Feature\
**Tags:** moderation, groups, trust-levels, category-moderators, revisions\
**Created:** [2026年五月22日 21:31 UTC](https://meta.discourse.org/t/split-delete-all-posts-and-topics-allowed-groups-into-own-content-and-global-content-permissions/403671 "2026-05-22T21:31:18Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\
**Post date:** [2026年五月23日 08:11 UTC](https://meta.discourse.org/t/split-delete-all-posts-and-topics-allowed-groups-into-own-content-and-global-content-permissions/403671/2 "2026-05-23T08:11:05Z")

</div>

我认为这里的部分混淆可能源于“查看已删除内容”的检查之间存在区别。

查看 `PostGuardian`，单个已删除的帖子似乎并不会仅仅因为用户属于 `delete_all_posts_and_topics_allowed_groups` 就在 `can_see_post?` 中变得可见。

例如，单个已删除帖子的可见性似乎是通过以下逻辑判断的：

```rb
def can_see_deleted_post?(post)
  return false if !post.trashed?
  return false if @user.anonymous?
  return true if is_staff?
  post.deleted_by_id == @user.id && @user.has_trust_level?(TrustLevel[4])
end

```

因此，属于 `delete_all_posts_and_topics_allowed_groups` 的非管理员 TL2 用户，并不一定能够通过 `can_see_post?` 打开或阅读所有已删除帖子的正文。

然而，相同的设置也在以下位置被使用：

```rb
def can_see_deleted_posts?(category = nil)
  is_category_group_moderator?(category) ||
    @user.in_any_groups?(SiteSetting.delete_all_posts_and_topics_allowed_groups_map)
end

```

这意味着该设置在概念上仍然比“作者可以撤回自己的内容”更广泛。它似乎既用于删除其他用户的可见帖子，也用于至少某些已删除帖子的可见性或列表展示功能。

因此，我的担忧并非“该设置肯定会在每个端点暴露所有已删除帖子的正文”，而是当前的权限将几个概念混合在了一起：

1. 删除其他用户的帖子/主题；
2. 在某些上下文中查看或列出已删除的帖子/主题；
3. 赋予作者对其自身足迹的更多控制权。

对于我的使用场景，我只需要第三种功能。

这就是为什么我认为一个针对“自有内容”的独立设置会更清晰。它可以允许用户删除或撤回自己的帖子/主题（在现有安全措施的约束下），而无需授予对其他用户内容或已删除内容可见性的更广泛的管理权限。

---

_[View the full topic](https://meta.discourse.org/t/split-delete-all-posts-and-topics-allowed-groups-into-own-content-and-global-content-permissions/403671)._