（一个人的功能请求是另一个人的错误报告…… 
）
“群组”索引页面（例如 /groups 或 /g）应尊重自动群组的可见性设置，并据此进行显示。它对 Moderators 群组执行此操作，但对其他群组不执行。这是由于 GroupsController.index() 中存在硬编码的例外情况，导致其他自动群组在非员工用户查看时永远不会出现在索引页面上，无论可见性设置如何。
这种例外行为至少在两个方面存在问题：
- 如果管理员希望为非员工用户索引自动群组，这将阻止他们这样做。
- 可见性设置与实际可见性之间的脱节非常令人困惑。特别是，这使得设置似乎被忽略/无关紧要，就好像自动群组（例如，“嗯，我想自动群组总是仅限员工使用，无论我将其设置为多少……”）一样，即使该设置确实继续控制对特定群组页面（例如
/g/trust_level_0）及其成员列表的访问。
相关代码中的一条注释表明，这种例外行为是为了“向所有非员工隐藏自动群组以使页面不杂乱”——但没有必要通过此机制来实现这一点。希望使索引页面不杂乱的管理员可以像对待任何其他群组一样，根据需要设置自动群组的可见性。
我建议从 app/controllers/groups_controller.rb 中删除实现此行为的 6 行代码。
如果将“使索引不杂乱”视为对 Discourse 新安装的重要事项，那么更好的机制将是为系统首次创建自动群组时，将自动群组的可见性默认设置为仅限员工。
（可见性设置是访问控制——默认值应构成合理的默认访问级别，而与索引页面的外观无关。）
供参考，此主题是以下讨论的后续：
7 个赞
simon
3
作为一个普通用户，我更喜欢简洁的视图，信任级别组对我来说似乎并不重要。但我也同意现在的工作方式似乎很奇怪。特别是考虑到这一点：
如果信任级别组页面有用，那么应该有一种方法可以通过用户界面访问它们，而无需知道 URL。
这对我来说很有意义。可能需要采取一些措施来确保限制信任级别组的可见性不会破坏任何东西。目前，如果用户创建事件时 TL0 组不可见，则无法创建公共事件。我不确定是否还有其他类似的情况。
5 个赞
RGJ
(Richard - Communiteq)
4
那么，这是否可以通过以下方式轻松解决：
- 在非管理员的过滤器下拉菜单中提供“自动群组”？
- 使默认过滤器（管理员和普通用户均适用）排除自动群组
- 确保
/g/trust_level_0?asc=true 使用与 /g?type=automatic 相同的授权逻辑（目前前者有效，而后者显示“没有可见的群组”。
附加请求：如果 /g 是通过 /admin 访问的，那么管理员菜单栏会突然消失。我觉得这很烦人。如果管理员访问 /g，是否可以为该页面添加那些菜单栏？
3 个赞
Moin
5
3 个赞
是的，“常识”如人所说……我已经编辑了我的原始提案以反映这一点。“可见性”是一种访问控制，应该像这样对待（例如，UI应该透明地反映控件的状态，而不是控件被扭曲来调整UI的外观）。
确实如此！我没有注意到非员工在过滤器下拉列表中无法使用“自动”。（它被隐藏自动组的同一 6 行代码块所省略——因此删除该代码也能解决这个问题。）
后端代码确实已经定义了一个“非自动”过滤器，尽管它似乎从未向任何人（员工或非员工）在过滤器下拉列表中提供。
2 个赞
您说“为非员工用户索引自动组”，您的意思是非员工用户可以访问自动组过滤器并看到它们吗？
这是一个合理的担忧。我们正试图让管理员体验更简单、更一致，而这似乎是一个可能让人们陷入困境的领域。我没有听到关于这个特定案例的其他投诉，但我可以看到修复它以使行为一致的价值。
这两点似乎都有道理。但是，在我们这样做之前，更改自动组的可见性设置是否有任何意外后果？
这看起来像一个不错的待办事项列表。感谢您这样构建它。
2 个赞
在引用的文字中，我特指“在非员工用户查看时，在 /g 索引页面上显示自动群组”。无论筛选器设置如何，目前非员工用户都无法在 /g 索引页面上看到自动群组（“版主”除外）。
在后面的帖子（此帖子之前的那个）中，我另外主张将“自动群组”选项提供给所有用户，而不仅仅是员工用户。我认为没有充分的理由将其隐藏起来不让非员工用户看到。（请注意，无论下拉菜单中显示什么，任何能够输入正确关键字到 URL 栏的用户仍然可以使用该筛选器。）
请注意，我在你发帖之前编辑了我关于默认去重化的建议；你引用的是原始版本。我第一篇帖子中修改/当前的版本是（为简洁起见，已删除删除线）：
2 个赞
当前，新网站上的用户列表如下所示。
用我自己的话来总结，这个请求是更改 /g 处的群组目录，如下所示：
- 也为成员显示“自动群组”过滤器
- 选择过滤器时，向成员显示所有自动群组
- 从
/g 的默认视图中排除自动群组
我觉得（3）应该对所有人（而不仅仅是成员）都适用。我们的目标之一是让管理员和版主拥有与成员几乎相同的体验，以减少混淆。
通过进行此更改，我们只是在 UI 中明确了成员可以访问但目前需要知道 URL 的自动群组的存在。
管理员：
成员：
我会这样重新表述要进行的更改，并稍微调整优先级：
A. 停止为非员工用户从索引中删除自动群组
B. 停止为非员工用户从下拉菜单中删除“自动群组”过滤器
C. 向所有用户在下拉菜单中提供“非自动群组”过滤器
D. 在 /g 中默认启用“非自动群组”过滤器
我特意将 C 和 D 的表述与 3 进行了对比：我认为用户界面应该非常清楚地说明正在应用什么过滤。如果未选择过滤器，则用户界面应显示未过滤的视图，即显示用户可见/可访问的所有群组。
有人可能会将 3 理解为“当未选择过滤器时，则悄悄使用 non_automatic 过滤器”，但我认为这仍然会令人困惑。如果未选择过滤器，则根本不应应用过滤器。反之，如果应用了过滤器，则应命名并告知用户。
深入研究细节：部分过滤器选择问题源于“按群组类型过滤”提示被挤压到未选择过滤器菜单项的标签中。我认为，如果未选择过滤器的菜单项标记为“所有群组”，最终会更清晰。然后，添加一个额外的“非自动群组”项目，您可以随意将其中任何一个设为默认项。这样，(a) 用户就能清楚何时获得过滤视图，(b) 用户就能清楚如何切换到未过滤视图。
如果由我来决定，我会这样标记过滤器菜单项：
所有群组我所属的群组 （因为“我的群组”有歧义。）我拥有的群组公开群组私有群组 （因为“关闭”听起来像是“已停止”或“不再使用”。）自动群组非自动群组
并且，我会将 文本框 中的提示字符串从“所有群组”更改为“按群组名称过滤”。
而且……我会将下拉菜单和文本框的顺序对调！
2 个赞
感谢您帮助我思考。我认为目前不太可能对群组列表用户体验进行重大更改，但我确实喜欢至少让群组列表对每个人都发挥相同作用的想法。
这些建议都很好，除了我觉得“自动”和“非自动”这两个词听起来笨拙、技术化，而且意义不大。鉴于自动群组都与人们获得或被授予的权限有关，也许我们可以想出一个能反映这一点的标签？
1 个赞
我也有同样的想法，认为最好将默认视图设置为现在所说的“公共+封闭群组”，从而引入这样的选项。消除“我的群组”的歧义，这可以被理解为“我拥有的群组”的实际含义，并且消除“封闭群组”听起来像是它们不再活跃，似乎也是合理的。
这些听起来很像：
也许此筛选器项中提供的群组顺序可以配置，第一个项目始终是默认视图，这样我们就可以选择它。否则，找到一个适合所有人的默认顺序，并允许其中一个视图成为默认视图，这将是另一个问题。
此外，能够为“自动/系统群组”提供人类可读的名称别名，例如某些语言喜欢首字母大写，就像常规群组中的全名字段一样，并为它们提供可选的、合理的默认描述文本，可以使它们看起来不那么“技术性”，如果网站管理员不选择通过其管理菜单在描述中解释它们。
也许还可以通过图标或其他方式来区分“自动”和“非自动”群组，例如图标，或者它们的框被着色为浅灰色，或者其他什么。
4 个赞
simon
18
“自动”听起来像是指一种实现细节——用户被自动添加到组中。从普通用户的角度来看，我认为这没有多大意义。它也不完全准确。用户不是自动添加到员工组的。也许“预填充组”是自动组最准确的名称，但这名字太糟糕了。
“系统”组听起来还可以，但将自动组分为“信任级别”和“员工”怎么样？组类型过滤器将是：
- 我的组
- 我拥有的组
- 公共组
- 私密组
- 信任级别
- 员工
如果需要，可以有一个类似 trust level groups public 的站点设置，用于确定信任级别组是否在组页面上可见。
3 个赞
分离出网站工作人员是个好主意。人们可能会喜欢在这里发现版主和管理员的列表。否则，他们必须知道去 /about。
3 个赞
再次插话……请将我也计入那些不需要“显示除系统/自动组之外的所有内容”过滤器的 Discourse 用户/管理员之列。那些组的存在似乎并不那么碍眼。
无论如何，我的首要任务是提供一个真正的“所有组”未过滤的过滤器，我个人的偏好是保持简单，让它成为 /groups 页面的默认设置。
