谢谢 @denvergeeks，但这并非来自付费订阅计划——所有费用都由我自己承担（除非偶尔有会员的小额捐助可以抵消一部分）。
您是在自托管吗？
感谢 @Nathank
是的，我已经安装了那个自定义向导插件，但到目前为止还没有成功实现我想要的功能。
看起来最适用的功能被标记为仅限订阅者使用，我不能排除其他方法——但到目前为止，还没有优雅的解决方案能够处理识别具有私人论坛成员的合格特征（通过下拉/多选自定义字段确定）的人员，同时将其他所有人过滤为公共论坛申请人的复杂性。
也许我甚至不尝试——也许我只是在批准注册时，根据收到的申请人回复手动分配组成员身份。（但这对于公众来说是一个糟糕的注册体验）
还有一个
是的，你说得对。你需要免费社区订阅才能使用这些功能（尤其是“添加到组”），这会增加一些麻烦。但仍然可以做到。
感谢 @nathank 。
我已经提交了免费社区订阅的申请——看看结果如何。
我必须承认，我有点担心会永久依赖一个随时可能改变其“免费”政策的插件。如果它真的改变了政策，是否有退出途径？
可以；如果订阅因任何原因失效，向导仍将可用；只是对该订阅者功能的更改将被锁定。
回顾此线程，您无法使自动化生效确实有些奇怪。这听起来像是一个严重的错误——而且我可以重现它。
对于您的用例，最好提倡修复该问题，并将自定义向导插件视为一种变通方法。
2 个赞
我的用例也很相似。我正在创建一个私有的（对我来说是付费的）社区，但我希望允许访客在不付费的情况下创建账户并查看有限的（预告片）内容。（不允许匿名访问，所以我设置了“需要登录”。）
当您处理好所有事情后，@Paul_King 您介意总结一下您最终使用的插件、您最终使用的设置（包括自动化和验证等）以及任何注意事项吗？提前感谢。
@nathank 我是否正确理解，如果我有一个访客组和一个（付费）会员组，我可以通过更改“所有人”的安全设置来限制对分类的访问？（并且要小心检查所有子分类，因为安全设置不会继承？——这是我昨天学到的，很不直观，而且可能很危险！https://meta.discourse.org/t/subcategory-does-not-inherit-security-settings/101122）特别是，访客的信任级别不会提高，以至于他们可以自行授予更多访问权限，对吗？
另外，@nathank，这是什么意思？
您的意思是会员不能在会员分类之间交叉链接（完全不能）到另一个会员分类，如果它（完全，即会员）受到安全限制？这是个沉重的代价！
此时我正在重新考虑是否值得尝试允许登录的访客，以便获得潜在客户。
@denvergeeks 由于我的社区是付费的，也许我可以升级我的托管以访问 Discourse Subscriptions 插件。我本来计划使用 ThriveCart，因为我的课程（可选，社区外部）将通过它付费，然后我可以将课程、指导、社区会员资格等捆绑在一起，并将所有财务交易集中在一个地方。
是的，就是这么简单。
除非组也拥有父类别的访问权限，否则您无法授予对子类别的访问权限；这可以很好地防止您提到的危险。
没那么糟糕——你仍然可以很好地链接，但漂亮的 Oneboxes 不会生成。
不幸的是，开箱即用的它只与 Stripe 集成。否则，它将是您的理想选择。
1 个赞
谢谢 @nathank，我已经将此报告为 bug。
与此同时，我的流程的一部分将要求所有现有用户自动获得“私人论坛”的群组成员资格（到目前为止，我还没有明确使用群组，论坛默认就是私有的）。我找不到一种明显的方法可以做到这一点，而不必发送（冗余的）加入邀请，并且要求每个现有论坛用户进行响应，仅仅是为了保留访问权限。
我有一种糟糕的不安感，实现这一目标的唯一方法是通过一些糟糕的数据探索器查询。
1 个赞
是的，在 Digital Ocean 上自托管
无需担心！
如果您有用户名或电子邮件列表（例如，从 /admin/users 导出），您可以直接将其复制并粘贴到群组页面的 
部分。
小菜一碟！
据我记忆，如果您有超过 1000 个用户，它会遇到困难。但您应该没问题。
1 个赞
感谢 @nathank
查看对话，按目前的措辞，它确实有点像只是为那些用户创建邀请，而不是真正地将他们转移？
它足够聪明，可以添加已有账户的用户，并向没有账户的用户发送邀请。
我知道，因为是我要求的！但是的，文案可以写得更好，嗯？
去用几个测试用户测试一下。
1 个赞
感谢 @nathank。它正如你所说的那样奏效了，是的，它确实很巧妙！
当我将 Excel 中清理过的电子邮件地址列粘贴到对话框时，它很高兴地识别出这是逗号分隔的。
在我的情况下，即使一次只粘贴 500 个用户，我也经常遇到“错误 502”——这似乎是一个服务器瓶颈问题（我的托管计划对网络和 CPU 利用率有限制）。
将一次粘贴的用户数减少到 200 个，几乎都能稳定工作，但如果我在批次之间留出更长的时间，一次可以粘贴更多用户。
我的下一步是想办法在自定义用户字段变量“私人论坛”之间建立某种双向同步链接，以实现或阻止对“私人论坛”组的访问。通过 Discourse Automation 仍然无法做到这一点。
目前，注册的测试账户只勾选了“公开论坛”框，但仍然可以完全访问两者。
我新的自定义用户字段，用于公开和私人论坛访问，也显示在用户配置文件中，这可能会引起混淆，特别是现有用户的这些字段是空的。
最好是将该字段仅对管理员可见，或者对仅限公开论坛的用户显示为灰色。
如果能有一种方式让论坛管理员直接提名或覆盖可访问的用户组，从而指定分配给用户的类别，并在“批准用户”对话框中首先批准用户，那将非常有帮助。
事实上，整个用户个人资料可能都应该从此对话框进行编辑——以允许清理自定义用户字段中已识别的用户错误。
目前，在注册时整理个人资料问题的唯一方法似乎是除了批准用户之外，还需要在其他区域进行大量跳转——因此，管理员出错或遗漏的风险会显著增加。
好的，一个更新
我终于让 Discourse Automation 正常工作了——诀窍是使用下拉自定义用户字段类型（尽管说明中没有明确说明这一点），而不是我一开始使用的复选框字段类型。下拉选项需要与完整用户组名称完全对应。
非常重要——请确保此新字段在注册后不可由用户编辑，否则，仅获准访问公共论坛的用户之后可以单方面授予自己访问私有论坛的权限。
2 个赞
您好 @tgustilo
我似乎已经解决了问题，而无需任何第三方插件。
我只使用了内置的 Automations 插件，关于它的一个技巧和注意事项已在此线程的上方发布。
我（目前）放弃了使用条件注册用户对话框，该对话框会根据用户想要访问的论坛显示不同的信息。因此，没有 Discourse Authentication Validations 或 Custom Wizard Plugin。
对于公开论坛的申请者来说，结果并不那么优雅，但某种程度上，将用于私人论坛申请者的专业资格和工作角色等自定义用户字段暴露出来，以捕获申请公众成员的其他专业资格和角色，并在其公开个人资料中显示，这可能是有用的。
这些信息意味着任何与该人互动的人都能更好地了解可能与其专业水平和领域相关的知识。
从这里开始，我非常希望管理员能够直接编辑用户申请，并在批准之前完成所有操作——所有这些都在同一个批准对话框中完成。
这样一来，那些试图申请访问私人论坛但显然不符合条件的人（基于提供的其他信息），至少可以被授予公共论坛用户组的成员资格，而无需从头开始重新申请（浪费了他们的努力），并且任何其他明显的错误都可以在一次操作中得到纠正（也许会有一个颜色编码的标志警告用户他们编辑过的个人资料字段）。
目前，处理已提交的申请用户个人资料（包括用户选择的用户组）中的问题，要么需要直接拒绝用户的申请，几乎不提供任何详细解释，要么需要进行单独的多步骤且容易出错的清理过程，管理员犯错或遗漏的风险很高。
3 个赞
我也希望为我的情况实现一个这样的申请流程，完全通过自动化插件控制，并且理想情况下，正如你所说，能够在批准过程中调整申请人的组成员身份、个人资料字段以及其他任何内容。
管理员的申请和批准工作流程将有多种用途，从处理普通会员（或试用会员、或对免费内容访问有限的会员）到为私人、付费或承诺会员提供更复杂的入职流程。
我还认为，能够筛选出优秀的 beta 测试人员和初始成员会很有用，这也是我目前面临的挑战。我希望有一个广泛的、开放的选项供任何感兴趣的人参与，但我确实需要筛选出谁将成为具有很大影响力的强大初始或核心成员。
如果有人正在建立一个支持社区来配合课程或辅导服务，初始注册自动化也可以将这些人引导到合适的队列或辅导/支持小组。
因此，将自动注册/申请与灵活的管理员批准相结合有很多用途。
我同意，能够配置一个单一的、官方的、免费的插件，而无需额外付费，对于没有资金或（任何/许多）付费会员的初创社区来说非常有帮助。
感谢分享你的流程。非常有帮助。
1 个赞