当我们尝试在“工作人员”分类下为管理员（版主也有相同问题）创建子分类时，会出现以下情况：
“任何被允许访问子分类的群组，也必须被允许访问父分类。以下群组拥有访问其中一个子分类的权限，但没有访问父分类的权限：管理员。”
但是：
版主确实拥有“工作人员”分类的访问权限，管理员也是如此。因此，我们应该能够执行此操作。
我管理另一个已存在多年的论坛，那里的“工作人员”分类下设有仅面向管理员或仅面向版主的子分类。
各位有什么看法？
[编辑：出于好玩，我截取了尝试创建仅管理员分类时显示的实际标签：
这有点滑稽，因为 (a) 管理员确实拥有访问“工作人员”子分类的权限，而且 (b) 管理员可以访问任何地方……因此默认情况下他们拥有任何分类的访问权限。
当然，您无法编辑“工作人员”的安全部分，以明确将版主和管理员添加到整个分类中。]
你需要确保创建的子类别仅对工作人员可见。你曾尝试创建一个对所有人开放的子类别，但在创建时未注意到权限设置，因此你认为这并非事实。
我正是这么想的，所以我删除了之前的消息。但请再仔细阅读一下错误信息：
“任何被允许访问子分类的组，也必须被允许访问父分类。以下组拥有其中一个子分类的访问权限，但没有父分类的访问权限：moderators。”
所以我尝试后遇到了同样的问题。
我尝试创建一个子分类，将安全设置设为“moderators：可查看/发帖/创建”，但依然收到相同的错误信息，尽管 moderators 理应包含在“staff”中，且父分类的安全设置已设为“staff：可读取/发帖/创建”。
听起来可能是个 bug，但为什么不把太阳类别的权限设为仅管理员可读，而不是版主呢？
我认为出现这种情况是因为权限是按用户组而非能力来设置的。
版主同时属于staff 和 moderator 两个用户组。
但如果存在一个staff 分类，其下有一个moderators 子分类，那么对于仅属于moderator 用户组的用户会发生什么呢？他们可以访问子分类，却无法访问父分类，而 Discourse 不允许这种配置。
理论上，如果你想让 moderators 能够访问某个子分类，你本可以在父分类的权限设置中添加“moderators：可查看/发帖/创建”，但在默认的 staff 子分类上这是不可行的。
此外，这样做也没有意义，因为 staff 意味着包括版主和管理员，而管理员可以访问所有分类。
需要有人来验证。但据推测，用户可能被添加到 moderator 组，而无需拥有 moderator 权限。而 Staff 则需要具备 Moderator 或 Admin 权限。
是的。但我们确实是这样做的。我们移除了“所有人”权限等，只保留了管理员或版主作为可访问该子分类的组。但这不起作用。
虽然以前是可行的。而且，根据权限规则，这应该是可行的。
我认为可能是这样。
由于隐私和其他问题，有些内容只有管理员才能查看。因此我们需要仅管理员可访问的子分类。
版主子分类是为了方便：将关于版主主题的讨论集中在一个特定区域。由于管理员本来就能看到所有内容，我们可以将它们标记为“版主专用”，但实际上对全体工作人员开放，这样也能行得通。这将解决一半的问题，当然，这算是“变通”做法。
但另一半问题我们无法解决。我会编辑原始帖子以反映仅管理员可访问的设置。
这是不正确的。版主可以访问工作人员分类。因此，设立版主（或管理员）子分类是（或应当是）被 Discourse 允许的。规则是：任何能够访问子分类的组，也必须能够访问其父分类。
但设立一个仅限管理员的子分类绝非毫无意义，因为版主无法看到管理员所能看到的所有内容。
请仔细阅读我的消息：就系统当前的设计而言，其运行方式是正确的，您遇到的错误属于正常现象。论坛的访问权限完全取决于用户组。
Discourse 自动创建的默认“工作人员”分类，仅对 Staff（工作人员）组可用。
如果您想为 Moderators（版主）组创建一个子分类，这将无法生效，因为父分类仅对 Staff 组可用，而不对 Moderators 组开放。
版主之所以能访问父分类，是因为他们同时也属于 Staff 组。
您仍然可以创建一个名为“moderation”（ moderation）的子分类，并将权限设置为“工作人员可阅读/发帖/回复”，这样就能正常工作。
这确实毫无意义，而且您可以毫无问题地创建一个仅对 Administrators（管理员）组可用的分类或子分类。
明确一下：我认为这确实是问题的根源。我原本打算在解释中提及这一点，但后来决定直接发帖而没有这样做。
不过，在这种情况下，这是一种隐蔽的漏洞：你制定的规则并没有反映出制定这些规则的原因。很明显，版主（mods）是工作人员（staff）的一部分，管理员（admins）也是如此，而这一原因理应允许他们在“工作人员”类别下创建子类别。
事实上，几年前，确实可以在“工作人员”类别中为管理员或“仅”为版主创建子类别：这显然是合理的。
为什么只为管理员创建一个子类别会是毫无意义的呢？
但在“工作人员”类别中不行。请查看上面的截图。
我的意思是，正如你所说，这并非没有意义。
是的，你说得对。
如果你想创建这些子分类，你应该创建一个名为“新闻员工”的父分类，并将权限设置为“管理员、员工、版主可阅读/发布/创建”，我猜是这样。
为什么不直接创建一个新类别，就像提到的那样？员工是一个专门的群体。
我可以将用户添加到多个组中。仅仅因为某些用户属于 B 组，可能也属于 A 组，并不意味着 A 组对某个类别的访问权限自动赋予 B 组访问权。然而，信任级别类别权限在最低层面上运作。
我不确定，但我想你可能可以编辑员工权限，以允许版主组直接访问。
Discourse 中不存在分层权限。Staff 是管理员和版主的特殊集合。子分类无法指定父分类中不存在的用户组，而且“工作人员”组的访问控制列表（ACL）是固定的。正如“工作人员”分类中所注明的那样：
警告：这是一个预置分类，无法编辑其安全设置。如果您不想使用该分类，请将其删除，而不是重新利用。
这并不是一个缺陷，只是您的使用场景不适合默认的“工作人员”分类。想要尝试不同的做法本身没有错，但如果因为无法将内置分类用于不同的用途就认定这是缺陷，那就不对了。
很明显，您并不想原样使用该分类。您可以创建一个新的父分类，允许管理员和版主访问，然后在其下为每个子分类单独设置子分类，这没有任何障碍。
这是一个关于类别权限警告系统的极小缺陷，因为它不知道 staff 等同于 admins + moderators。不值得为此来回争论 12 个帖子。
你可以通过将 admins 和 moderators 显式添加到父类别的允许组中来规避此问题。请注意，管理员仍然可以访问 moderators 子类别。
是的。但版主无法访问管理员子类别。
在一般情况下确实如此，但在“Staff”类别中无法这样做，因为该类别是自动创建的，且无法更改其权限，而这正是问题的核心。鉴于：(a) “Staff”类别会在每次安装时自动填充；(b) 出于可用性考虑，限制类别数量非常重要；以及 (c) “Staff”类别曾经能正常工作，我认为这一请求并不过分。
我的建议是一个简单的解决方案。目前，在自动创建“Staff”类别时，会设置以下权限（且无法修改）：
staff 可以创建/回复/查看
相反，在自动创建“Staff”类别时，Discourse 应设置以下权限：
staff 可以创建/回复/查看
admins 可以创建/回复/查看
moderators 可以创建/回复/查看
通过这一简单的修复，该错误将得以解决，我们无需创建额外且无用的类别，同时“Staff”类别也能像过去一样正常工作。
我认为你的观点有些本末倒置。为特定用途创建一个专用分类，远比修改一个内置分类要简单得多，尤其是考虑到已有数千个安装实例正在使用现有的权限配置。
实际上，如果您仔细阅读我的解决方案，您会意识到它是向后兼容的，并且能让之前的安装像以前一样正常运行。
但这与向后兼容性无关。在这个话题中，你是唯一一个推动变更的人。你提出的方案仍然需要开发时间、测试以及后续维护。数千个安装实例使用现有配置正常运行，意味着也有成千上万的管理员和 Moderation 团队对当前设置并不介意。
这个话题已经存在数月了。你本可以在四月就按照正确的方式实施变更，为何却期望 CDCK 为单个站点出资修改其软件？该软件以这种方式运行已有七年之久。如果你不愿意对自己的配置做出最简单的调整，又凭什么要求任何人做任何事？你不愿遵循指导，这无法激励他人采取行动。
正如数月前提出的那样，人员分类并没有什么特殊之处，你可以创建一个具有相应权限的不同分类。问题就此解决。
对你而言，在自己的社区中实施一个小改动，比上述任何方案都要简单得多。
这并非正确的做法——但我确实在四月就实施了它。我们通常不会等到 bug 被修复或功能被实现之后，才着手整理我们自己的事务。
是的，是的，不。我曾多年担任软件开发者和管理者，非常清楚修复一个 bug 需要付出什么。这个修复只需要几分钟的开发时间、几小时的测试时间，并且不会比当前版本需要更多的维护。
按照你的逻辑，那就完全没有必要开发任何新功能了。既然有成千上万的团队在使用 Discourse 的现有版本，为什么还要再花哪怕一小时去开发呢？让我们争论时讲点逻辑吧。
这是一个毫无根据且无礼的假设，鉴于我上面的评论，这显然是站不住脚的。
实际上，你错了。在很长一段时间里，它是以不同且更好的方式运行的。这里有一个现有的托管 Discourse 系统的示例，该系统已有 4-5 年的历史，拥有一个原生的 Staff 分类，允许 Moderator 子分类：
问题的关键与我的系统无关。我不需要这个变更来让我的系统运行。关键在于，每一个 Discourse 系统自带的 Staff 分类在功能上都逊色于它本可以达到的水平，也逊色于它曾经拥有的水平。如果 Discourse 费心自动创建一个 Staff 分类，为什么不将其设计得更好、更完善呢？我提出的建议简单且易于实施，能够帮助我们这些处理多类 Staff 人员的人恢复有用的功能。团队可以自由考虑我的建议，也可以不考虑。
警告：此类别为预置类别，无法编辑安全设置。如果您不想使用此类别，请将其删除，而不是重新利用。
只需重新创建工作人员类别，并将主题移至新类别即可？
