我刚刚在我运营的一个论坛上遇到了这个问题。复现步骤：
- 以管理员身份创建一个新群组
- 将可见性设置为“群组所有者”
- 创建群组
- 返回到
/g - 群组不会显示
如果你通过 Group.find_by(name: <name>) 检查控制台，它会正确返回。将可见性更改为“群组所有者和工作人员”后，可见性就会正常显示。
除非这是按设计如此，否则我的假设是，即使是管理员也应该能看到此可见性级别的群组（但版主除外）。
我直到昨天升级到 2.4.0.beta2 时才注意到这个行为。
重新加载有帮助吗？
不，即使调用 JSON 端点，该群组也不会显示为管理员。
我最近刚处理过这个，会去查看一下。
是啊。这看起来不像是你会忽略的事情，但当时我只有这个。
我无法复现这个问题，@justin。我在本地环境和 DigitalOcean 托管的实例上都尝试过，并且使用两个不同的管理员账号创建了群组。在所有情况下，管理员都能看到所有群组。
奇怪——我得在 fresh install 上试试。我确实在现有的生产实例上复现了这个问题。我会先尝试更新，然后再看下一步怎么做。
我在全新安装上尝试了，结果和您 @pmusaraj 一样。我猜可能是我使用的某个插件导致的。如果查明原因，我会回来反馈。
我也遇到过这个问题……
你们也在用插件吗？具体是哪些（重点关注那些 Discourse 本身不创建和预装的）？还是说 Justin，你是在指出这是一个新的回归问题？
你好，我刚刚将一个组的可见性从“仅群组所有者”更改为“群组所有者及成员”，它又重新变得可见了。我想知道，当群组的可见性被限制为“仅群组所有者”时，相关的设置代码是否存在某些异常？
@outofthebox 您碰巧安装了 Babble 聊天插件吗？在我从实例中移除该插件后，似乎出现了与之相关的回归问题。卸载该插件并重新构建后，群组可见性已恢复。
找得好 @justin，我快速查看了 Babble 的源代码，发现它与我核心中关于分组的更新存在冲突。Babble 为 visibility_level: 4 添加了一条硬编码规则，现在这与核心中的 owners 组发生了冲突。
希望 @gdpelican 有时间查看一下。
如何解决当前 Discourse 版本中的这个问题？
我应该删除这段代码吗？.where.not(visibility_level: 4)
@@visible_group_scope = method(:visible_groups).clone
scope :visible_groups, ->(user, order = nil, opts = {}) {
@@visible_group_scope.call(user, order, opts)
}
end
好的，我已经更深入地调查了这个问题。
看来 babble 为了自身用途分配了自己的 visibility_level，并占用了下一个未使用的常量（4）。
几周前，Discourse 核心代码也添加了一个新的 visibility_level，同样占用了下一个未使用的常量，也就是 4。这导致了该常量的重复使用。
因此，修复方案应包含两部分：
- 更改 babble 使用的
visibility_level。这很简单。如果我们想做得更规范，可以让每个插件注册自己的BASE_VISIBILITY_LEVEL以避免未来的冲突。但目前我们可以先随便选一个值（例如 1001）。 - 将
visibility_level为 4 的组更改为新常量——但仅针对由 babble 使用的组。
@gdpelican，这个查询能选出正确的组吗？
UPDATE groups
SET visibility_level = 1001
WHERE id IN (
SELECT g.id
FROM topics t
LEFT JOIN topic_allowed_groups tag ON tag.topic_id = t.id
LEFT JOIN groups g ON g.id = tag.group_id
WHERE t.archetype='chat');
你好，抱歉，我会在接下来的几天里查看这个问题，但你对修复方案的总体概述非常准确。向后移植将会比较棘手，我很快会仔细查看。
好的，我已经为这个问题推送了一个修复。如果您遇到其他异常情况，请告诉我？
我发现一个问题：Backfiller 功能似乎缺少多站点支持（它需要遍历可用的连接）。
@RGJ 你愿意为那个提交一个 PR 吗？我可以合并，但接下来几天网络连接有限。
好的，我这周末就能做到。