因此，对于预填充的“网站反馈”类别，在编辑时，安全选项卡下会显示一条警告。
警告：此类别为预填充类别，安全设置无法编辑。如果您不想使用此类别，请将其删除，而不是重新利用。
我理解锁定“员工”类别安全规则背后可能有充分的理由。然而，预填充的“休息室”类别的安全规则并未被锁定。我认为“网站反馈”类别应与“休息室”类别一样对待，允许编辑其安全规则。
我不确定是否忽略了允许编辑“网站反馈”类别安全设置可能带来的某些不利影响。该类别的其他所有选项似乎都未被锁定。
我也正计划将该分类迁移到不同的安全设置。希望能通过一两次点击轻松更改设置。
所有人均可… 创建 / 回复 / 查看
2 个赞
休息区的设置是：用户必须达到 TL3 级别才能获得访问权限。从某种意义上说，休息区是对那些积极参与社区的用户的一种“特权”或“奖励”。如果您更愿意更改访问此类类别的资格要求，为什么不直接创建一个具有您所需安全权限的新类别呢？
至于站点反馈，您是否认为，因为用户是新用户且未达到更高的 TL 级别，他们就不会提出对社区有益的建议？这听起来有点像“如果你是新用户，我们不想听你说什么”。
我从未尝试过，但可能可以创建一个具有您首选安全设置的新类别，移动所有帖子到新类别，然后删除原始类别。只需确保将其重命名为不同于 site-feedback 的名称即可。
此前已讨论过这个问题（试图更改预置类别的安全设置）。那么，为什么不直接创建一个符合您要求的新类别，并删除预置的类别呢？
2 个赞
说得有道理，@JimPas，你说得对，删除并重新创建确实是一个解决方案。我认为这不算个大问题，只是觉得默认情况下允许编辑该类别的安全设置会更理想。
在许多情况下，允许新用户发布反馈可能是更理想的做法。我只是觉得，默认将各类别的安全设置锁定，对所有的社区都这样处理，可能有点过于主观。通过锁定设置来降低灵活性，我看不出有什么明显的好处。
再补充几点具体原因：
-
安全锁定的一个原因，至少根据所显示的消息来看，是为了防止类别被重新用途。不过，管理员可以随意重命名类别及其 slug，也许出于疏忽，将类别重新用途（只是无法编辑安全设置选项）。
-
有些管理员可能希望向未登录用户和网络爬虫隐藏“网站反馈”类别，同时仍允许所有已登录用户（包括新用户）查看并发布反馈。
-
在某些情况下，管理员可能希望创建更具体的“网站反馈”子类别，并禁止在父类别中发帖，从而迫使用户选择合适子类别来发布反馈，以优化话题组织。我认为如果不编辑安全设置，这是无法实现的。
-
管理员可以删除该类别并创建一个新类别作为变通方案。但这对于已经运行了一段时间的论坛来说可能并不理想。新类别将拥有不同的 ID 和 URL，会导致指向该类别的静态现有链接和外部链接失效。不过，他们可以使用“永久链接”选项作为变通方案，将旧类别重定向到新类别。
1 个赞
这正是我的情况。过去几个月，我们 Discourse 论坛的开发非常活跃，但现在人们开始按预期使用它（作为邮件列表的替代品）。我们有许多已解决的帖子涉及论坛的设置和维护，普通用户对此完全不在意。
我们有一个主分类（未分类），并鼓励所有用户只需在希望提供反馈时 @staff。我们甚至在新主题草稿页面的描述中加入了这一提示。此外，我们还设有专门的主题“在此报告任何论坛问题”，用于同步我们是否已更新并实现了该线程中请求的功能，同时鼓励用户参与。
完全正确。这并非关于限制访问这些数据的问题。如果你走进我家，我不会把建筑图纸和账单随意散落在地板和桌子上。如果人们需要这些信息，他们可以通过其他方式获取……例如通过管理员组或类似渠道，让用户可以更灵活地选择加入或退出。
这是在日常使用与那些明确希望测试实验性功能的用户之间寻求平衡。
在我们的论坛上并非如此，而是：在什么阶段我们应该隐藏脚手架/限制社区用户（他们真正希望推进事务）看到繁重的施工内容。
3 个赞
在我们的论坛上，我们有一个名为“站点反馈”的类别，还有一个名为“META”的类别。
在 META 类别中，用户可以就他们遇到的具体问题创建新主题。一旦问题解决，这些主题会被标记为“已解决”。而“站点反馈”类别则保持最初创建时的状态。不过我要说明的是，我们是一个小型论坛，成员们大多来自另一个现已关闭的论坛，彼此已经相识 7 年以上。
2 个赞
在我们的论坛上，我们有：
关于分类，以前称为“元讨论”。我们有一个自称“元讨论”的群组，因此我们决定将该分类名称赋予他们，以减少混淆。这不算什么大问题，但我们希望隐藏此关于分类，让未登录且无需查看它的人看不到。此外，将其限制为仅一个简单的公开群组可能也有意义。工作人员分类——用于存放一些我们不想让论坛变得杂乱的随机集成和技术帖子。我们尚未尝试使用“工作人员备注”功能，因此该分类目前承担了这一角色。
我注意到几乎所有讨论都发生在“未分类”中，这是我们默认的讨论区域。人们很喜欢使用标签，但可能因为允许任何人创建标签而过于宽松。
这是我的主要理由。连登录都没有的人可能并不关心论坛的设置。他们只想看到一般的讨论等内容。
2 个赞
如果用户不想接收“网站反馈”分类下的帖子，他们总可以在偏好设置中静音该分类。这应该能防止他们在“最新”中看到来自该分类的不需要的帖子，甚至整个分类。如果他们偶尔想查看，可以随时向下滚动分类列表并从中进入。
但我觉得这开始稍微偏离了 @markersocial 最初的问题——允许修改“网站反馈”分类的安全规则。
（继续讨论分类的不同用途仍然很有意义。）
为什么用户不能在“网站反馈”分类中直接创建一个与其具体反馈相关的新主题呢？我们的“网站反馈”分类中已有多个由用户创建的主题。它更像是一个建议箱，用于提问。当用户遇到问题时，他们会发布在我们恰如其名地称为“Meta”的故障排除分类中。
针对您提出的原因，一个简单的解决方案是：
- 创建一个名为“反馈”的分类，
- 创建您希望用户在其中创建主题的任何子分类，
- 然后设置主分类，使任何人都无法在其中发帖。
但是……该设置是否会阻止用户在子分类中发帖？
我从未尝试过。听起来像是一个有趣的实验，但我马上就要去睡觉了。也许明天我会试一试——除非有团队成员在这里介入，解释这是否可行。
1 个赞
谢谢 @JimPas
所以我认为主要的问题是，对所有安装锁定预置的“站点反馈”类别的安全设置有什么好处？
我实在想不出这样做有什么好处，这似乎是一个不必要的障碍，而且移除它也没有任何坏处。新安装可以默认获得推荐的安全设置，但同时允许针对超出该范围的使用场景提供灵活性。本质上就像 Lounge 的预置类别一样。
这不算大问题，毕竟正如你所建议的，可以通过删除并重新创建它来绕过这个问题 。不过，如果论坛已经运营了一段时间，随着论坛的发展需要修改这些设置，这样做就略显不够优雅，因为这会改变该类别的 URL（可以使用 管理 > 自定义 > 固定链接 来辅助处理）。
是的，没错，他们可以在“站点反馈”类别中创建专门针对其反馈的主题。不过，在某些使用场景下，强制为每个主题使用子类别可能更有用，特别是当论坛属于一个拥有多个面向用户网站/应用和产品的多元化品牌时。
几个例子（不过它们并没有强制使用其子类别）：
https://community.cloudflare.com/c/feedback/25
有些反馈可能涉及公司的主要产品及其特定分类方面，有些则可能涉及论坛本身。本论坛本身就有一个 站点反馈子类别 用于博客，该类别还分配了不同的标签组。
关于这一点，我之前曾对一些类别使用过这种方法（禁止在父类别中发帖，但允许在其子类别中发帖）。子类别的安全规则不受父类别安全规则的影响。因此，这确实是一个可行的解决方案。
1 个赞
谢谢。这省去了我自行排查的麻烦。今天因为3岁的小孙女突然来访，她只想让爷爷陪她玩，结果我白白浪费了差不多5个小时。
现在终于可以去看看我自己的论坛了。
1 个赞
这是为了应对技术限制而采取的变通方案——如果我们（Discourse）希望更新默认设置或更改该分类的翻译名称，而有人将预置分类当作“普通”分类使用，那么一旦我们更新默认设置，该分类就会自动发生变化，这将造成极大的混乱。（是的，这种情况确实发生过。这就是设置这些限制的原因。）
阻止您修改安全设置，是为了提醒您该分类具有特殊性，且默认设置可能会更新。
由于自动更新功能是使这些分类具有特殊性的唯一原因，帮助文本会建议您直接删除该分类并创建一个新分类，而不是将其重新用作其他用途。
4 个赞
啊，有道理。谢谢你的解释 @riking。
如果重新利用该类别非常有害（我并非鼓励这样做），那么在“重命名类别”设置中添加一个警告是否更合理？安全规则似乎与这些潜在问题没有直接且强烈的关联。
我想强调几点：
- “闲聊”类别似乎同样处于自动更新的状况中，但其安全设置是可以修改的。
- “站点反馈”类别可以被重新利用（重命名标题和 slug），而几乎不会察觉到安全规则被锁定。它拥有与新“普通”类别相同的安全规则默认值。
- 锁定功能会阻止一些相当简单的更改，例如仅对登录用户显示该类别，或将其限制为特定的信任等级。
据我所知，lounge 是一个普通类别，仅用于演示 ACL 和信任等级访问权限？
1 个赞
@Stephen - 我看到 lounge 类别在 postgres 的 ‘site_settings’ 表中被引用。我不太确定这有多大意义，但猜测它的处理方式类似。当我在测试实例上修改 ‘meta_category_id’（站点反馈类别）时，重建时会影响站点反馈类别。
@markersocial 除了逐个移动主题外，您是否有将约 100+ 个主题从预填充迁移到新自定义类别的建议？
1 个赞
@sunjam 这里有一个解决方案：Bulk move many topics from one category to another - #2
我刚刚在测试实例上测试了一下，运行正常，不过只涉及少量主题。
因此，请 SSH 登录到你的服务器，然后使用以下命令（在此示例中，类别 2 中的所有主题将被移动到类别 1，请根据需要替换这些数字）：
cd /var/discourse
./launcher enter app
rails c
Topic.where(category_id: 2).update_all(category_id: 1)
你可以从类别 URL 末尾的数字中获取类别 ID。
编辑：唯一的问题是，它也会移动“关于此类别”的帖子，而且似乎无法通过管理界面将其移回或删除。可以将其设置为不显示，但不确定这是否会引起问题。稍等一下，我会尽快更新。
编辑 2：要将“关于此类别”的主题移回正确的类别，只需使用以下命令（其中主题 ID 为 1，目标类别 ID 为 2）。我刚刚测试过，可以正常工作：
Topic.where(id: 1).update_all(category_id: 2)
你可以像获取类别 ID 一样，从主题 URL 的末尾获取主题 ID。
3 个赞