在将组添加到类别时，可以选择 anonymous_users 和 logged_in_users 选项，但它们不起作用。
2 个赞
这是否不需要启用“细粒度的匿名和已登录用户组权限”这一 Beta 功能？
1 个赞
@martin 对此有什么想法吗？
1 个赞
感谢报告，我会查看一下 
根据你在另一个话题中的回复
我越想这个问题，就越感到担忧。
如果我只向某个分类添加“匿名用户”而不添加“已登录用户”，会发生什么？
如果我的论坛设置为“需要登录”，同时我添加了“匿名用户”，会发生什么？
此外，目前的技术实现是：当分类权限设置为“所有人”时，category_groups 表中根本没有条目，且 read_restricted 设置为 false。
这非常简单直接：如果没有设置权限，则权限由全局论坛权限（login_required 设置）决定，不再应用其他限制。
因此，做出这种更改将增加巨大的复杂性，并可能导致各种奇怪的组合（你可以同时设置“匿名用户”和“管理员” 
）
我的建议是：
- 完全移除分类权限中的“匿名用户”选项
- 保留“所有人”和“已登录用户”
- 移除“信任等级0”选项，因为它等同于“已登录用户”
或者作为替代方案，但对于经验不足的管理员来说可能不太清晰：
- 移除分类权限中的“匿名用户”和“已登录用户”选项
- 保留“所有人”（和信任等级0）
在所有情况下，都保留“所有人”。而且你也不需要迁移数据 
4 个赞
感谢你的想法，这就是为什么我一开始不想在那个“所有人”变更中过多深入类别权限的问题 
我认为你在这里说的很多内容都可以简单地通过限制来实现。我已经在我们开发的看板插件上着手构建一些基于 ACL 的初步系统，并设计了更友好的权限 UI。这里有一个示例，我们打算最终将类别权限改为使用这种方式：
这里涉及几条规则，例如无法为匿名用户分配看板的管理员权限，等等，甚至支持强制权限，比如管理员始终可以管理看板。
我们会限制在论坛需要登录时无法添加匿名用户。
同样，这也是我们可以添加的验证/限制之一。
我们也可以针对这类情况添加验证或警告。
这正是我想要避免的。Discourse 中到处都是这种隐式权限，而不是在类别公开或未限制阅读时，始终显式地配置“已登录用户 + 匿名用户”。
总之，目前我不想对此深入探讨，在处理类别之前还有很长的路要走。但我确实同意原帖中提到的问题是一个需要尽快修复的 bug，所以我还是会进行此项修复。
1 个赞
考虑到另一个问题，我个人不建议采用这种逻辑。如果我在匿名用户已在权限列表中的情况下，将论坛更改为需要登录，会发生什么？反过来呢？这将是一场噩梦，而且管理员将无法清楚地了解情况。
我对这种复杂性非常警惕。
2 个赞
再次强调，这里有很多值得深思的要点，而且这事儿确实挺棘手。在调整分类相关功能时，我肯定会把管理员的体验放在心上。这里的历史包袱不少，我可不想让任何人感到意外。这一切都不会一蹴而就，等我着手这个项目时，需要花很长时间仔细推敲各种场景。
1 个赞
我想知道，为什么在类别权限的上下文中，可以为匿名用户配置内容而不能为登录用户配置内容是一个问题，但在通过站点/插件/主题设置配置的权限上下文中却不是问题。一个简单的例子：现在可以让匿名用户访问样式指南，而无需添加登录用户。这比向匿名用户显示类别但不向登录用户显示类别更有意义吗？
1 个赞
说不通，这真的只是另一个需要处理的边缘情况……我会为那个插件把 anonymous_users 加到 disallowed_groups 里。另外，我也很怀疑野外有多少站点启用了这个插件，所以目前不太担心它被错误配置的问题。
我觉得处理这类设置时，我通常就是这么做的。我们也可以利用 mandatory_values 来确保某些组始终被选中，这样你就不会在某些地方只剩下 anonymous_users。或者利用设置验证来规定“如果没有至少一个已认证用户组，就不能选择 anonymous_users”，等等。
我不明白为什么需要这样做。把它作为一个选项有什么问题吗？
这仅适用于站点设置，还是也适用于主题组件？
目前还不适用于主题组件，但将来可以。再说吧，我们现在有点跑题了。