当新用户通过邀请链接加入时，我发现我目前也需要批准该用户。
这违背了邀请的全部目的；我不如直接发送论坛链接给他们。
我已经尝试过在多种情况下（新链接、旧链接、单人、多人）在多个实例上进行此操作，结果都是一样的。
我已将这些实例的 /admin/site_settings/category/all_results?filter=must_approve_users 设置为 TRUE。它似乎过于字面化了！我只想批准那些没有邀请而加入的用户，这才是过去的操作方式。
6 个赞
如果您设置了 must approve users，则明确表示每个用户都必须经过明确批准。
我们出于 Discourse 用户的安全考虑不得不更改此设置。
我猜可以把论坛改为“仅限邀请”、“需要登录”？然后限制可以邀请的人。
2 个赞
我以为来自管理员的邀请就是明确的批准——尤其是当它包含用户的电子邮件地址时！
当然，公开邀请存在滥用链接的很多机会。但是，管理员必须故意设置链接以允许这种情况发生，并且可以轻松地承担（并限制）该风险。
这也意味着偶然发现我网站的人无法加入，除非他们能找到人邀请他们，否则就会被排除在外。这很糟糕。
建议
如何在 /admin/site_settings/category/all_results?filter=must_approve_users 中添加两个选项？
- 管理员必须批准所有用户
- 除非由管理员邀请，否则用户必须获得批准
- 仅公开注册需要管理员批准
- 无需管理员批准
3 个赞
很高兴将此添加到功能请求存储桶中，可惜我们目前没有精力在此处进行额外的保真度工作。
3 个赞
是的，不过这个行为在一个月前被更改了：
我们有一个由慈善/工会用于技能培训的实例，它也受到了类似的影响。
在此更改之前，员工可以邀请用户绕过批准，现在他们必须同时进行。由于需要返回并验证每次批准与成员列表，这大大增加了他们的管理开销。
7 个赞
是的……我猜长远来看，解决方案是添加一个站点设置，允许选择加入宽松的审批模式。
但我担心，因为在这里确保安全非常非常困难。我们允许的边缘情况越多，复杂性和潜在的安全漏洞就越多。
5 个赞
我想知道主要边缘情况是否只是允许在邀请中包含特定电子邮件地址时覆盖“必须批准用户”设置，并为匿名邀请链接保留“必须批准用户”设置——但这在后端可能比我想象的要复杂。
5 个赞
这对我来说很有意义，特别是如果邀请是针对特定电子邮件地址并且是由员工发送的。在这种情况下，我认为不需要第二级批准。
6 个赞
是否可以允许管理员设置一个“自动批准”标志，并可选择将其限制为“未更改电子邮件”或“仅限一次”之类的选项？在我的例子中，我甚至愿意接受一个命令行邀请程序，它可以创建这些特殊的预批准邀请，是否有这样的东西可用？
恐怕没有。
作为一个糟糕的变通方法，我已经按照 Sam 的建议做了：
我已经相当慷慨地向我们的论坛散布了邀请，这效果很好。
问题在于那些通过 Google 搜索或其他方式偶然发现该网站的“不请自来者”。他们必须通过电子邮件发送加入链接，这给管理员带来了很大的麻烦。
Arman 的建议非常简单，我认为实现起来（或容易泄露）不会太难：
这有可能实现吗？
4 个赞
\u003e
目前，如果 must_approve_users 为 TRUE，情况并非如此：
每次我们要邀请一群人时，我们都要么接受很多麻烦（审批步骤），要么必须暂时重新配置站点（并停止公开注册），这非常痛苦。
关于这是否会有一天发生，有什么想法吗？
2 个赞
不反对，但目前还没有安排。
2 个赞
您好，我也想请求一项功能，允许员工邀请绕过批准步骤，也许可以在“生成邀请”对话框中添加一个可选的布尔值。
目前，对于启用了 must_approve_users 的站点，“分享此链接可即时授予网站访问权限”的说法完全不成立。
解决方案似乎是如在“修复了安全问题的 bug 讨论主题”中“选项 4”中所讨论的那样，但这给我们留下了“预先批准”邀请链接的问题。
总而言之，此请求是为了让启用了 must_approve_users 的站点的员工能够创建一个绕过批准步骤的邀请链接。尽管我运行的站点需要批准，但有时我们希望能够通过我们知道将私下分享给受信任个人的邀请链接来**“预先批准”**用户，或者在我们分享链接到与论坛社区相关的线下活动时。 （我们不一定知道此类受邀者的首选电子邮件地址，因此无法使用批量邀请）
2 个赞
对于我们（相对）庞大的 must_approve_users 网站，在举办线下活动时，这仍然是一个很大的麻烦。
问题在于，我们无法简单地给人们一个漂亮的二维码、邀请函或链接，让他们直接登录我们的实例。至少，不能在没有一些笨拙的变通方法的情况下做到这一点。
变通方法及其问题
关闭 must_approve_users 并将网站设为 invite_only 并不是一个令人满意的解决方案，因为：
-
许多人似乎搞砸了任何邀请流程，并试图通过（现在已锁定的）“前门”进入。
-
活动产生的热潮通常也会影响到未受邀者——但他们也无法申请加入。
-
仍然存在一个错误，即分阶段的用户在注册时会丢失其自定义用户字段输入。
- 这会搞砸替代路径（除非使用完全外部的电子邮件地址）。
2 个赞
自变更以来，目前的情况无疑使事情变得更加困难。我曾合作过的技能培训慈善机构受到的影响最大，他们在几周后选择关闭了他们的社区。
每周有数百人来来往往，这增加了太多的管理负担。
2 个赞
感谢您再次提出这个问题。我认为我们已经到了需要进行一些修复以使邀请更轻松、更无缝的“三顾茅庐”的阶段。邀请系统已被证明很难更改，因为似乎每个人都在以不同的方式使用它。我们需要明确的指示，并尽量避免破坏他们的工作流程。
我会与团队核实，看看我们能做些什么。
这对我来说是新闻，我们单独来看这个问题。
2 个赞
据我所知，我们上次更改只需要一个设置和一个商定的默认值。
我们从所有员工邀请绕过审批改为所有邀请都需要审批。
2 个赞
你说得好像很简单！
我们的顾虑是，站点可以有很多不同的设置方式，然后也期望邀请系统能以不同的方式工作。安全是一个非常现实的问题。因此，在对邀请系统进行任何进一步更改时，我们将谨慎行事。
我个人认为，以下方法是最好的，因为它不依赖于管理员设置，并且在邀请模态框上直接清晰地说明了行为。即使是完全不熟悉 Discourse 的人，也很难意外地创建和共享一个他们不期望的邀请链接。你们怎么看？
- 当启用
must approve users管理员设置时 - 在邀请模态框上向员工显示一个开关，用于创建绕过批准要求的邀请。例如
[ ] Do not require approval by staff - 兑换邀请时，如果选择了（2）中的开关，用户将无需批准即可进入站点
假设只有员工才能访问此开关，因为 must approve users 设置的目的是让员工控制谁可以加入社区。
如果需求足够，我们以后可以考虑添加一个管理员设置，以确定哪个组可以访问此功能。
3 个赞
Sam 甚至将这次更改称为“出乎意料的复杂”。我毫不怀疑他的话。
原始更改加上这次更改的总工作量显然会大于从一开始就考虑过的情况。我们当时确定，虽然一个社区发现当前的默认设置令人反感，但有几个社区依赖于这种行为。例如，放弃其基于 Discourse 的技能培训网站的工会并非轻易做出决定，但一旦员工邀请的学员在通用批准池中丢失，他们就无法继续下去。
如果问题在于缺乏明确的理解，那么在“必须批准用户”和提供员工邀请绕过批准选项的邀请模式之间可能需要一个中间步骤，否则可能仍然会出现导致此次更改的原始投诉。
所以更像是：
- 当“必须批准用户”管理员设置已启用，并且新的“员工邀请绕过批准”设置从默认的“从不”更改时：
- 如果设置为“始终”，则旧行为生效
- 如果设置为“可选”，则在模式中显示开关，以提供绕过后续批准的选项
没有中间步骤，管理员并未完全意识到“必须批准”的含义，而一点点的粒度将解决忘记使用切换开关时出现的其他问题。
2 个赞
我认为这会非常好地工作（也许还可以加上 @Stephen 的调整）——而且我喜欢这是一种以人为本的方法，不会破坏任何东西，因为它会使默认的机制完全保持不变。
然而，对我来说，一个非常重要的边缘情况是与群组邀请相关的自动电子邮件邀请。这允许通过一次管理员操作将人员添加到群组或向他们发送邀请，具体取决于他们是否已注册。就个人而言，我也确实需要以某种方式涵盖这一点。
1 个赞