我已经阅读了该主题，该主题基本上声明不需要此功能，所以我不会再要求了。
但是，对于像我这样拥有庞大社区的社区来说，存在一些用例，其中主论坛内实际上存在较小的论坛。可以想象一下游戏文化中的“氏族”。
这些子社区采纳论坛的主要规则，但也有一些特定的附加规则和一个专门的团队，他们负责审核该版块并领导他们，但这无关紧要。
版块版主无法针对用户本身采取行动，只能针对版块，但是，在我的用例中，如果他们违反了某些子论坛的规则，他们应该能够阻止某些用户参与。
我真正需要知道的是，核心功能是否足够精细，能够让版块版主阻止特定用户访问他们的版块。
我的设想是，会生成一个自定义表，其中包含 category_id 和 user_id，当用户尝试访问特定主题或版块时，只需检查该表即可。
我是否离题太远了？这是否可行？我在软件开发方面经验丰富，但对 Ruby 几乎一无所知，所以我真的不知道该从 Discourse 源代码的哪个地方开始寻找以了解应该在哪里查找 
您可以只允许宗族类别中的成员发帖，并移除您不希望在该类别中的用户。这需要您希望在该类别中的每个人都成为该群组的成员。
很棒的讨论主题。
最简单的解决方法是信任等级。
在需要“禁止”用户时将其降级，并要求该类别需要高信任度。
最近遇到了完全相同的情况，我只是将用户锁定在TL 1，而该类别需要TL 2。搞定！
我也做了同样的事情。而且因为我不允许任何人自动获得高于TL2的级别，所以这在精神上和管理上都是一个非常简单且不复杂的解决方案。它也带有一丝优雅 
我很久以前为一位客户做过这个。信任级别对我们来说行不通，所以我们为每个类别创建了私有组，每个用户都会自动加入，类别版主是这些组的所有者。
“封禁”就像移除会员资格一样简单，这意味着管理员无需做任何工作。
开始时需要稍微多花点精力，但之后几乎不需要任何工作。
但是，如果组是动态的，该如何实现呢？
例如：我的一位客户有一个论坛，其中有一个“待售”类别，TL2 及以上用户可访问。
他们希望禁止某些成员在此处创建主题，但他们需要复制并维护一个组，该组包含与 TL2 相同的人员，但排除 5 个特定用户。
也许可以通过类似的方式，根据某个标准（检测是否晋升到 TL2？）将用户分配到组中，然后在必要时将其移除？仅仅因为 TL2 是入门标准，并不意味着你需要依赖该 TL2 状态来确定成员资格，对吗？这也取决于你是否有时间和资源在你的实例上或围绕你的实例进行工程设计。
我并没有建议这是一个一劳永逸的解决方案。如果他们不想做额外的工作，这可能不适用于他们的用例，但对于我的客户的例子以及实例被划分为公会/氏族/或其他什么的场景，这可能是一个不错的选择。
但是，如果我们要在实例上进行工程设计，那么我宁愿拥有类别禁止功能 
这样也更易于维护。如果我有 50,000 个用户，并且需要他们都能访问该类别，但有少数用户除外，那么很难列出这少数用户。
我的意思是，禁止只是排除的另一种说法，而 Discourse 实际上并没有排除权限。当“非包含”实际上是同一件事时，它还需要存在吗？我喜欢显式允许模型，它能让故障排除变得轻而易举。
我仍然会偶尔做噩梦，想起多年前试图解决 vBulletin 的允许/拒绝模型。我经历过的与此相关的痛苦和债务比 RSOP 还要多。
我感谢所有关于替代解决方案的意见，但我问的是一个具体的技术问题，而不是我试图弄清楚的妥协方案 
我会说是的
@crius 我们可以通过插件来实现，我认为你可以通过覆盖类别序列化器中的 permissions 在客户端上实现很大一部分功能，并在服务器端使用 NewPostManager.add_handler 添加额外的检查。
您是否考虑过使用用户组？创建一个包含 2 个用户组的类别以进行访问。1 个用户组是您的类别版主。另一个是您的子论坛参与者。参与者用户组需要请求访问子论坛区域。您的类别版主，其中一些或全部，是该用户组的所有者。如果某成员违反了需要将其踢出子论坛的规则。将其踢出参与者用户组，并与其他类别版主沟通踢出时长。
那么，不幸的是，您可能需要考虑赞助一个插件。这就是众筹插件将是一个很棒的概念。核心团队最终可能会添加您所请求的内容，但由于开发列表的优先级，可能需要一些时间。
不过，另一方面，通过群组建议，也许可以使用主题组件添加一个从群组踢出的选项。
你确定问对问题了吗？
我的意思是你的主要目标是解决一个问题，而类别禁令只是你尚未解决的答案。正确的问题应该是我如何解决问题X以及我的选择是什么。
我评估了使用 TL 或用户组来管理此事的可能性，但这将增加版主的工作量，在大型社区中这根本不可行。
用户组尤其不利于精简的用户体验。
我不需要寻求赞助，因为我拥有丰富的软件工程师经验，而且还有其他同样经验丰富的人。我们只是不使用 Ruby，这将是唯一的拖累。
不过，还是感谢您的意见。我很欣赏这个论坛倾向于非常有主见，但就软件本身而言，最好遵循一种更“提供选项”的方法，当然，代码方面的复杂性会增加，而另一方面则是权衡。
非常感谢 @RGJ 的见解 