你好。
现在我们可以授予特定组访问低语的权限，我们非常接近于移除我们大多数内部用户的主持人访问权限。
而且，当我们开始移除访问权限时，我们意识到还缺少最后一块，不得不撤销更改。我们在组织中大量使用分配（给用户和组）。
所有这些都对我们的用户社区“隐藏”了。这对我们来说确实有效，因为有时我们会将帖子分配给一个组，因为……
内部用户可以被信任将帖子分配给组织中的其他组。
当我们开始撤销主持人访问权限时，我们意识到组可见性和分配给组的能力只能开放到“仅组内成员、主持人及管理员”，否则我们就必须允许非内部用户查看和分配给组。
如果这些权限也可以在组级别进行定义，那就太好了。对我们来说，这是最后缺失的一块。
驱动我们的因素：
我认为提及我们为何踏上这段旅程很重要。
我们的实例大约有 170 名主持人。这些用户不需要访问我们用户的电子邮件地址和 IP 地址。特别是随着我们组织的不断壮大，让每个人都能访问这些信息感觉很危险。
说实话，我不知道有这个选项——而且，我们的实例上它被关闭了！我冒充了我们实例上的另一位版主，确实，他们无法查看电子邮件地址。
我发誓，当我“仅仅”是版主（而不是管理员）时，我曾有权查看电子邮件——也许我们当时有不同的设置（在过去的 8 个月里，我们的实例经历了很多变化）。
非常感谢你指出这一点。
所以这确实减轻了一些紧迫性——总的来说，我仍然希望看到该平台朝着灵活的基于组的权限发展，而不是这些更僵化的选项。
抱歉，您能详细说明一下吗？
我们也在 Discourse 上处理类似的问题，事实上，我在我们的开发实例上没有管理员/版主访问权限。我完全理解您关于保持管理员/版主数量低的有益之处。
您能说清楚问题吗？
请记住，有几个构建块可以依靠：
类别版主，您可以将特定类别的版主权限定义给特定组。这为高信任度用户提供了更大的灵活性。
信任级别系统……在 TL4（手动）级别，许多功能将被解锁。
assign allowed on groups 站点设置（该设置允许为特定组分配）。
好的。很高兴能详细说明。
我们公司有很多不同的团队，他们是我们社区的专家（SME），负责我们产品中各自负责的部分。为每个团队创建一个小组，当某个主题需要某个团队的专业知识时，该主题就会被分配给该团队（通常还会分配给个人，当个人贡献完他们能做的所有事情后，就会从自己身上取消分配）。
我们不想向用户透露这一切是如何运作的。我们试图降低期望（我们为开源用户提供免费支持），我们不希望用户开始问“为什么不能马上把这个分配给_____团队？？”——事实上，我们不希望我们的用户知道这些小组的存在。
通常，我支持彻底透明……但这对我们来说效果很好。
而且，我们希望我们的内部用户能够看到所有这些小组、分配给他们的话题，并能够重新分配给其他小组。
但是小组级别的交互权限：
被限制在以下权限：
这意味着，如果我们想确保我们所有的内部用户都能以我们需要的方式看到/与小组互动，我们就必须授予至少版主访问权限。这并不理想。
希望这能帮助您弄清楚问题。如果我能进一步说明任何问题，请告诉我。
我明白了，这确实是个棘手的问题。我百分之百同意，我们应该将此下拉菜单从：
改为：
允许哪些用户组访问 X：
[my-group/owners group1 group2 etc... ]
事实上，这可能会简化用户界面和内部实现，因为不再需要处理枚举等问题。
端口最难的部分在于“组所有者”不是一个真正的组，所以我们需要某种新的原始类型来描述它的含义。仅有组 ID 是不够的。
如果它是一个真正的群组，那将非常有帮助！
我关于此的特性请求：
老实说，我很难想到一个真正的用例，其中群组所有者不应该因为他们是群组所有者而能够做所有事情。
在这种情况下，您也许可以忽略该问题，并授予群组所有者超级权限。然后，其余的权限可以委派给各个群组。
我明白你的意思，但我非常担心进行破坏性更改。通过支持一个简单的“组所有者”影子组，我们可以完全迁移到新的 UI，而不会破坏该功能的现有用户。
当然，我完全理解您在这方面的观点！
