未登录时无效：
https://meta.discourse.org/u?exclude_groups=admins&order=likes_received
未登录状态：
已登录状态：
我偶然发现这个问题，是因为我注意到在退出自己论坛的登录后，按「收到的点赞数」排序时，我本人不再被排除在用户列表之外。
这是否是故意设计，以便即使设置了 /u?exclude_groups=admins，仍会暴露管理员组成员？
我认为这可能是因为默认情况下，未登录用户无法访问管理员组的成员。例如，您可以尝试 Meta 的管理员组：https://meta.discourse.org/g/admins。
您可以在组的设置中进行配置，这应该能解决您的问题（我尚未测试过）。
如果允许用户目录根据您不了解的组或您无权查看其成员的组进行筛选，就会泄露信息。这对管理员组来说可能不那么重要，但想象一下，如果您能根据 Meta 上隐藏的“企业客户”组来筛选用户目录，会发生什么情况。
在发帖之前，我访问了 https://meta.discourse.org/g/admins，该页面对于未登录用户是隐藏的。正因如此，我才发起了这个讨论。`/g/admins` 对未注册用户隐藏，但他们仍然可以通过访问 /u?exclude_groups=admins 看到管理员组的成员，这至少看起来有些奇怪。
现在我有些困惑。根据标题，我原本以为 /g/admins 和 /u?exclude_groups=admins 对已登录用户都应能正常工作，而对未登录用户则无法访问。
也许我们讨论的是群组页面中“隐藏”状态的不同含义：
当我提到“隐藏”时，我指的是类似私密的状态——未登录用户访问 /g/admins 会被重定向到“出错”页面。我想你可能想到的是，大多数用户（管理员除外）在群组页面上看不到默认群组，因为某些额外代码将其隐藏了。但即使这些群组未在群组页面上显示，用户仍可通过点击链接访问该群组的页面。
真正的“私密隐藏”才使群组成为秘密，这也是我认为用户目录中的过滤器不应生效的原因，否则会泄露信息。而仅仅未被显示的群组，并不属于秘密。
所以你将其限制为仅限已登录用户。如果你希望访客能够访问该群组，为何要限制可见性和访问权限仅对成员开放，而不是选择“所有人”？
你能详细说明一下这张截图想表达什么吗？
我看到你将群组的访问权限限制为已登录用户，同时也将群组成员的访问权限限制为已登录用户。
接着你向我展示，未登录的用户无法访问群组成员的数据。这在我看来是合理的。我原本以为，只有当你在两项设置中都选择“所有人”时，才会出现这种情况。
感觉你好像在说：“我想向访客隐藏管理员群组的成员信息。”但与此同时，你又抱怨这些数据无法用于筛选用户目录。
如果你连群组中有哪些成员都不被允许知道，自然也就无法排除这些成员。
我只是附和一下 @Moin 在这里的发言。如果我们让 exclude_groups=admins 生效，那么即使某人本不应拥有访问权限，他们也能推断出管理员组的成员。
因此，恐怕这是有意为之，且不太可能更改。如果你希望人们能够查知管理员组的成员，就需要将其设置为对所有人可见。
同样的逻辑也适用于任何仅注册的用户。如果一名全新用户注册并使用 exclude_groups=admins，管理员将从其列表中隐藏，因此他们可以通过比较过滤后和未过滤的列表来推断成员资格。
“推算出来”的门槛仅仅是创建一个免费账户，任何人都可以在几秒钟内完成。那么，在这里，未登录的访客与仅注册一分钟的账户之间真正的区别是什么？
作为背景说明，我真正想要实现的是：在侧边栏插件中有一个排名，而我只希望管理员组不被包含在“获得最多点赞”或顶级贡献者列表中。
这取决于网站配置——许多网站并不开放注册。
那么，调整该组的可见性是否是一个可行的变通方案？或者这样做是否存在问题？
：) 很多都是。我常去的大多如此
是的，这确实没错。但在安全功能方面，我们必须确保设计能够严格按照描述运行。如果有人决定隐藏群组成员身份，那么该功能必须 100% 可靠地生效。
为什么不将管理员组及其成员的可见性更改为“所有人”来实现这一点呢？这样数据将对访客可用，过滤器也应该能正常工作。特别是当你说任何人都可以登录并访问 /g/admins 时，未登录用户是否也能访问其实并不重要。
问题是，在这里隐藏会员身份其实并不可靠。在许多论坛上，包括我自己的，管理员本身就是最活跃的用户之一。因此，你只需按活动量对目录进行排序，通常就能立刻发现一两位管理员。
管理员组的成员身份很容易从公开的活动信息中推断出来。特别是因为 https://meta.discourse.org/u 默认就是按活动量排序的：
当然，你也可以隐藏所有个人资料。但我的观点是，在当前忽略 /u?exclude_groups=admins 参数的情况下，所声称的安全优势微乎其微，甚至可以说几乎没有，充其量只是表面功夫。
因此，在这种情况下，注册并不能真正增加安全性。无论是未登录还是直接创建账户，你都可以通过排序找出管理员，因为他们的活动水平始终是公开的，即使我尝试通过 /u?exclude_groups=admins 将他们从列表中排除。
这正是我最初报告该问题的原因。如果隐藏管理员是一项有意为之的安全功能，那么它理应优先防止非用户轻易推断出管理员身份。但现状恰恰相反：未登录的用户只需访问默认的 /u 页面，就能更轻松地找出管理员。
这种颠倒让我怀疑这或许并非本意。
编辑：
对我来说，回到主要问题，这甚至与安全性无关。那是你们提出的观点。我只是希望管理员的活动不会出现在侧边栏插件和 /u 页面的排名中。
我理解你的观点，但重要的是要考虑到群组安全系统并非专门针对 @admins 群组。如果论坛存在 @super-secret-lurkers 群组，相同的安全模型也必须适用于该群组；)
能够判断“不在某个群组中”本质上与能够查看“在某个群组中”是相同的。
没错，这说得通。将管理员群组更新为对“所有人”可见，对你来说可行吗？
不，我在发帖前已经试过了。我原本以为非成员必须能够看到该组，排除规则才能生效。
但事实并非如此，/u?exclude_groups=admins 对未注册访客完全被忽略。
这并非为了隐藏用户，而是为了隐藏关于谁属于某个群组的信息。因此，您可以在目录中看到隐藏群组的成员，但无法查看该群组的页面。您知道用户存在，但不知道他们是否属于某个秘密群组。
例如，您有一个面向客户 A 的群组，但不希望论坛的其他用户知道该群组的存在。此时，您可以限制该群组的可见性，但成员信息在其他地方仍然可见。您能看到他们发帖，也能在用户目录中看到他们，但您不知道他们属于客户 A 群组。
同样，您也可以限制管理员群组的可见性。访客不被允许知道哪些用户属于该群组，但他们可以知道这些用户正在使用论坛。
不，我只切换了“谁能查看该组成员？”的选项。
我不想启用“谁能查看该群组”，因为那会让 /g/admins 公开可访问。
不过我可以测试一下，看看是否能让 /u?exclude_groups=admins 生效。
稍后回来。