禁用“启用名字”会导致管理员行为异常

错误
29

我在 Restrict exposure of full name to certain groups 中对用例进行了一些背景介绍。我们正在使用 Discourse 来促进关于当地公立学校的讨论；目标用户主要是家长和其他当地社区成员。我们希望取得平衡：

  • 一方面，让网站可以匿名浏览（以便搜索引擎可以索引它，非会员也可以访问，原则上是开放/透明的……）
  • 另一方面，避免不必要地向爬虫和临时非会员公开个人身份信息——我们希望让人们在社区内分享他们的名字，并希望解决许多人在这样做时的顾虑。

最初，我们认为禁用“显示帖子名称”并启用“阻止用户公开个人资料”可以阻止向匿名用户泄露姓名——但后来我们意识到事实并非如此。（我们已经通过 TOS 和 FAQ 向人们承诺过这一点。:lying_face:）

只拒绝匿名用户访问全名就可以完成任务。但是，由于将访问权限与组成员身份挂钩同样容易，我认为不妨这样做——这为我们的网站提供了将访问权限限制在 >=TL1 的可能性，这更好。（目前，我们需要邀请才能注册，但我们想取消这个限制。）

在研究这个问题/主题时，我看到过其他提及相同或类似要求的，例如“我们只希望某某组能够看到名字”……这也可以解决那些用例。

有一个问题想问您（您甚至可以将其视为产品问题！）：

  • enable_names 设置的意图是 “不向用户显示全名” 还是 “此网站根本不使用全名”？

我的感觉（从代码本身以及从像这样的主题/问题中）是，在这点上存在根本性的不确定性——有些人按一种方式理解，有些人按另一种方式理解。

4 个赞
30

这个有什么进展吗？这似乎是最容易实现且影响最大的功能。

4 个赞
31

同意。管理员应该能够在不打开或关闭切换的情况下访问全名。特别是有一些重要的原因（至少对我们的论坛来说）隐藏真实姓名。

3 个赞
32

如果在这个话题上取得进展，我一定会非常感激。我们对它有即时且持续的需求。

1 个赞
33

感谢所有为这个帖子做出贡献的人。我只想礼貌地询问一下，这个问题是否会在即将发布的版本中得到解决，或者至少被确认为一个已知的回归。

目前禁用启用名称会以一种似乎并非本意的方式破坏关键的管理功能，而且对于这是否是设计使然还是一个错误缺乏明确的说明，这让我们很难进行规划。对于我们这些运行生产站点并且用户名优于全名的人来说，这种限制带来了真正的摩擦和意想不到的行为。

我知道必须平衡优先级，但如果能从团队那里获得关于这个问题是否在考虑之中的更新，那将非常有帮助。提前感谢您提供的任何见解。

1 个赞
34

嘿，@tobiaseigen，关于这个有什么工程方面的意见吗？（已经过去 3 个月了——但我也忙于其他事情而忽略了这件事，所以我也不能抱怨。）

我这周可以开始提交拉取请求，让对话更具体——但我担心它们会被搁置而无人审查，而且我也需要一些关于我方法某些方面的反馈。

编辑：需要说明的是，我指的是关于 Restrict exposure of full name to certain groups - #2 by mdoggydog 的实现的拉取请求（该功能允许启用“姓名”，同时控制谁可以看到全名）。

2 个赞
35

@RGJ @chrismalone 和 @mdoggydog 非常感谢你们的投入。我们仍然需要这个修复，并感谢所有致力于解决这个问题的人。

2 个赞
36

说实话，我很惊讶这件事没有引起更多关注。 我可以理解在不知道是否会被审核的情况下，对进行公关感到犹豫，并可能被实施。虽然我想象一个公关可能会变成一个插件，但是这将此选项更多地限制为自托管。

39

@mdoggydog 看起来你的解决方案是用一个接受群组列表的设置来替换 enable names 设置，并且成员的姓名仅对这些群组可见。

请注意，这仍然需要遵守 display name on posts 设置（以及任何其他可能存在的类似设置），因此即使是允许的群组，如果该设置被禁用，也不会在帖子中看到姓名。

此外，我们还需要修复/更改以下一些作为连锁反应的事情：

  1. 姓名应始终在用户配置文件的管理视图中可见。无论任何设置如何，情况都应如此。
  2. 姓名仅当用户位于允许的群组中时才应显示在电子邮件中。

以上应该可以解决当前的问题，并使此功能更加灵活和有用。

这听起来像你在这里提出的建议吗？如果是这样，我们肯定很乐意查看你提交的包含此更新的任何 PR（Pull Request，拉取请求）。

40

我写的代码并没有移除 enable names 设置，[1] 而是对其进行了补充：

  1. 添加一个 full_names_visible_to_groups 设置（其中 admins 和 moderators 是强制值）。
  2. 向 Guardian 添加一个 can_see_full_names? 方法，该方法执行 enable_names 和 full_names_visible_to_groups 中群组成员资格的“与”运算。
  3. 在服务器暴露/发出完整姓名的所有适当位置使用此新方法。

1 和 2 很简单。3 更复杂，我知道我遇到了一些困难，不知道如何解决，需要获得建议/指导。距离我上次深入研究这个问题已经过去 2 个多月了。（:see_no_evil_monkey:）

（如果我没记错的话，display name on posts 等是客户端设置，影响从服务器接收的数据的显示。换句话说，是在服务器发出的任何内容之上的一个限制。）

我相信（1）在 enable_names 为 true 时已得到处理，这可能是几乎所有人想要的，一旦新的按群组设置可用。[2]

我认为我遇到了（2）并已处理——大部分。[3]

我记得还有一些其他情况会泄露全名。[4]

无论如何，我将回顾笔记，并尝试在本周提交 PR，在此过程中找出未解决的问题/遗留问题。

  1. …原因有很多，其中：(a) 我不确定该设置的实际意图（参见我上面早期帖子中的问题），以及 (b) 保留它提供了更安全的增量升级路径。 ↩︎

  2. …如果一个人认为 enable_names = false 意味着“本网站在任何方面都不使用完整姓名”。 ↩︎

  3. 例如，当发送邀请电子邮件到某个地址时（显然与用户无关，否则他们就不需要邀请了），电子邮件是否包含邀请者的全名？ ↩︎

  4. 例如，oneboxer.rb 在 onebox 本地用户时，会将全名写入已烹饪的帖子内容中，这会使所有人永久可见。 ↩︎

4 个赞
41

听起来很棒！你能把你的PR链接发到这里吗？然后我会找一位工程师更仔细地查看。

6 个赞
42

第一个（2 或 3 个）PR 在这里：

此 PR 是后续 PR 的先决条件，它确保 Guardian 实例实际上是从一个序列化器传递到下一个序列化器。详细信息请参见 PR/commit-message。在我准备下一个 PR 时，也可以开始关于此 PR 的讨论。

我的迷你 GitHub 账户冒险

…嗯，它曾经在那里，直到我在这里的编辑框中输入 URL……然后我的整个账户突然被暂停了。:face_with_monocle: :weary_cat: :face_with_symbols_on_mouth: :crying_cat_face: :alien:

我已经提交了恢复请求，并在有更新时会在此处更新。

13 小时后，我收到了一封电子邮件，大意是：“有时会发生这种情况；现在一切都好了。” 非常卡夫卡式。我的账户从网站上消失了——以至于我多年前在 Issues/PR 中发布的帖子也消失了，只留下神秘的单方面对话，以及一些幽灵般的引用块作为曾经有人（我）在那里存在的唯一证据。

这似乎是极其严厉的措施，不仅对被暂停的账户是如此，而且对所有项目的历史被悄悄剥离的块也是如此。

3 个赞
43

我意识到这也会涉及到协调 discourse 插件仓库中的更改 — 这意味着一系列的 PR，以一种由内而外的顺序，以确保测试始终通过（当然，main 始终是可用的）。

我设想的顺序会是这样（其中 CORE 表示 “在 discourse/discourse 中的 PR”，PLUG 表示 “在官方插件仓库中的 PR”）：

  1. 强制执行序列化器作用域转发 （预计没有功能性更改）
    a. CORE 实现序列化器作用域检查，默认禁用
    b. PLUG 修复作用域转发的问题
    c. CORE 修复作用域转发的问题，并默认启用作用域检查
  2. 抢先在第 4 阶段需要的地方提供 Guardians（替换占位符）（预计没有功能性更改）
    • CORE 占位符修复
    • PLUG 占位符修复
  3. 实现简单的 Guardian#can_see_full_names?，该方法仅依赖于 enable_names （预计没有功能性更改）
    • CORE 将方法添加到 Guardian
  4. 在发出全名的地方使用 can_see_full_names?（根据需要替换对 enable_names 的裸使用）（可能存在功能性更改）
    • CORE 使用新的 Guardian 方法
    • PLUG 使用新的 Guardian 方法
  5. 实现 full_names_visible_to_groups 设置 （功能性更改）
    • CORE 将新设置添加到配置，并在 Guardian 方法中检查该设置

（1）和（2）归结为确保在整个 Discourse 代码库中更一致和可靠地使用 Guardians。

（3）和（4）是关于为控制后端何时暴露全名建立更精确的抽象（根据 Guardian 代表的任何上下文来决定暴露）。

（5）最终是（相对简单的）部分，其中全名暴露由组成员资格控制。

3 个赞
45

好的！我已经将一位工程师加入到此对话中，以便他能查看问题。听起来你思路是对的，但工程师能提供更专业的反馈 :slight_smile:

4 个赞
48

@hugh 感谢您将此事提交给合适的人员以推进。我们已经期待一段时间了。

1 个赞
49

抱歉，我必须拒绝此 PR。此更改过于复杂且难以维护。主要原因如下：

  • 范围并非总是必需的，不应强制执行；
  • 在所有地方（例如插件）更改并随后维护它将是一项艰巨的工作；
  • PlaceholderGuarian 并没有解决问题，而是添加了一个伪范围（意图稍后修复）；
  • 大多数情况下，序列化应在控制器中进行，并且范围将自动添加。

根据群组显示用户名或全名非常棘手。与其尝试将其合并到 Discourse 核心，不如先创建一个插件？如果您的社区规模较小，可以这样做：

2 个赞
50

我刚完成了一个解决原始问题的 PR。管理员将始终能够看到全名并进行编辑。我们将在下周初尝试合并 :crossed_fingers:

3 个赞
51

我认为关于 enable_names 设置到底应该做什么，仍然存在根本性的误解/分歧，这归结为这个问题：

  • enable_names 设置的意图是：
    1. “不在公共场合显示全名。”
    2. “此网站根本不使用全名。”

我认为这个话题上的一些人认为它是（1），而另一些人认为它是（2）。我的印象是后者，即 enable_names 决定了网站是否使用全名。

请记住，当 enable_names 关闭时：

  • 注册对话框不提供全名字段。
  • 用户在自己的帐户偏好设置页面上看不到全名字段；用户永远不会在任何地方看到自己的全名。

我不明白一个网站的用例，在这个网站上，只有管理员知道系统中存在全名字段。我的想象力不足让我怀疑这里是否有人真的想要这个。如果有人想要，请告诉我！

（我认为还存在一些关于我的草稿 PR 试图实现什么、如何实现以及为什么实现的误解——但我想先解决“enable_names 实际上做什么？”这个问题。）

2 个赞
52

是的，我可以举出很多例子。通常，拥有社区的企业在法律上有权（和/或需要）知道其客户的姓名，但隐私法禁止他们将这些姓名公布给第三方。这与大规模电子邮件中使用抄送（CC）是错误的，你应该使用密送（BCC）的原因 pretty much 相同。

嗯，这最初只是一个相当简单的 bug 报告，它只是行为不当。然后我们都开始讨论它的预期功能，这也引起了很多混乱和额外的讨论。这没关系，但最好是在一个 Feature 主题中进行。

是 #1。该设置的描述是：

在用户的个人资料、用户卡片和电子邮件中显示用户的全名。禁用以在任何地方隐藏全名。

全名被隐藏的事实意味着它确实存在，并且管理员可以看到隐藏的内容。

还有 display_name_on_posts、full_name_requirement 和 display_name_on_email_from。

如果你想要 #2，我想最好是基于 full_name_requirement 进行扩展，并在那里添加一个“从不”的选项。

（是的，我也同意 enable_names 应该有不同的名称，但重命名设置从来都不是一件有趣的事）。我也同意

很奇怪。

1 个赞
53

这个修复会恢复原始功能吗？即管理员和用户可以看到他们的全名？只是感觉这个更改最初引起了很多问题，与原始功能相比。即使是完整的版主也应该有一个通过设置查看真实姓名的选项，因为在某些情况下这是期望的/需要的。

在团队推送此更改后，任何输入了真实姓名的用户都变为空白。

依我看，此设置应分为两个具有清晰定义的设置。随着禁用姓名的较新功能，将其作为一个新的设置来关闭真实姓名。

我很幸运我的社区很小。想象一个拥有数千名成员的网站，他们的真实姓名被清空了。