我们一直在使用邀请链接来帮助用户在平台之间迁移到 Discourse；然而，随着最新 Discourse 更新开始出现的这个新提示正在导致延迟和混淆。
使用将用户重定向到主题帖子的邀请链接的用户不仅只能使用一次链接，如果我们要期望他们每次想访问主题帖子时都使用该链接，这是一个主要问题。重要的是，我们能够让用户使用同一个邀请链接重定向，无论用户想重新访问该主题多少次，而这个新提示阻止了此功能，这造成了一个问题。
还出现了其他技术问题。首先，点击“接受邀请”至少需要五秒钟才能响应，然后需要一些时间才能将用户重定向到主题。其次，有了这个新功能，加载提示本身就需要更长的时间。第三，即使您之前点击过邀请链接并接受了邀请，每次点击链接时它都会继续询问您！
要重现此问题，请创建一个将用户重定向到主题帖子和/或将他们添加到组的邀请链接。登录 Discourse 帐户后，点击重定向链接。
请问有什么方法可以在设置中禁用此提示吗？这既紧急又重要，因为这对我们来说会影响用户体验。
其他人可能也会忽略这一点，他们可能依赖邀请链接但不知道这个新变化，因为没有关于此变化的通知，谢谢！
我也想补充一点，这里也有一个 bug。在我们的用例中，我们根本不需要这个提示，所以能否将其移除？或者在管理员设置中提供禁用它的选项？
这个 bug 是，如果你第二次点击“接受邀请”，页面将保持静态，不会显示任何消息。这完全没有帮助。它阻止用户使用之前的上下文再次重定向到该主题。这是一个主要问题。如果我在文档中放置一个邀请链接，并期望读者可以一遍又一遍地使用同一个链接重定向到该主题，那么该邀请链接将不再有效。
我们使用邀请链接是因为参与者需要先被添加到私有类别中，然后才能阅读该主题。如果用户需要再次找到该主题，他们应该能够使用同一个邀请链接。在这种情况下，如果用户已登录，它应该自动接受邀请，因为该邀请是为该用户准备的，并且由于它以前运行正常，应该将用户重定向到预期的主题帖子。
邀请链接以前工作得非常好。我希望你能仔细看看这个问题，并让管理员可以选择禁用这个“接受邀请”的提示/按钮消息。谢谢！
感谢您的报告，@gassim。
我无法重现这种 5 秒延迟。在此处 meta 上使用添加或不添加组的多个邀请进行了测试。如果您每次都看到此延迟，下次能否在打开开发者工具的控制台选项卡时尝试一下，看看那里是否报告了任何错误？
我可以重现这个问题，看起来这里有一个回归，我们将尽快修复它。
这是 Firefox 控制台中 5 秒延迟的证据。
我在 Firefox 控制台中看不到任何错误，但当我尝试在 Chrome 中操作时，有时会看到这些错误。
includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
PUT https://XXX/invites/show/XXX.json 502
XMLHttpRequest.send @ includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
send @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:495
ajax @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:471
y @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
O @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
f @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
submit @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926
B._run @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450
B._join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4449
B.join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4412
p @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
a @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2481
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:719
_triggerAction @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:532
click @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:531
trigger @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2235
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
trigger @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4230
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
a @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4234
discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940
SyntaxError: Unexpected token '<', “<html\n<h”... is not valid JSON
at Function.parse [as parseJSON] (<anonymous>)
at i (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940:167)
at discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926:699
at b (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4291:12)
at g (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4289:128)
at h (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4287:107)
at p.invoke (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4377:192)
at p.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4369:141)
at h.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4384:207)
at B._end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4448:9)
at B.end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4401:240)
at B._run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450:118)
at B.run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4410:13)
at d (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577:23)
at u.error (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948:44)
at l (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:200:118)
at Object.fireWith [as rejectWith] (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:201:698)
at E (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:483:468)
at XMLHttpRequest.<anonymous> (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:494:206)
感谢 @pmusaraj 的帮助！
请问，在我们的使用场景中，提示消息没有帮助，管理员是否有办法在没有这种提示的情况下创建邀请链接？
邀请链接用于课程，参与者被邀请加入讨论论坛。我们希望邀请链接能做的就是将用户添加到群组并将用户重定向到私有类别中的主题（无需每次使用链接时都点击“接受邀请”），并且在首次点击后，用户应能够使用相同的邀请链接返回该主题。在消息提示被强制执行之前，这一切一直运行得很顺利。
我已经在另一个主题中解释了我们如何使用邀请链接
@tobiaseigen @dan @JammyDodger ，请帮帮我。我们必须能够摆脱我们使用场景中的提示消息。
谢谢 @yanokwa！(:
您好 @gassim，我们已在内部讨论过此事。抱歉，但同一个用户多次接受同一个邀请作为书签的行为是不符合预期的，我们将修复此问题，如果已登录用户已接受邀请，则隐藏“接受邀请”按钮。取而代之的是，我们将显示一条消息，告知用户他们已领取邀请链接。
打开页面时自动接受邀请是一个安全问题，因此我们改为使用中间的“接受邀请”页面。
如果用户有必要反复访问同一个主题，我们建议他们将其添加书签。或者，如果您在内部文档中放置了邀请链接，请在同一位置添加指向该主题的链接以方便访问。
嗨 @martin，感谢您和 Discourse 团队的考虑。我们目前正在讨论替代解决方案。
是的，请这样做，我们很乐意知道何时修复此错误。
明白了……我希望管理员在创建邀请链接时可以选择是否使用提示消息（也许会警告他们如果不使用提示消息可能会发生什么）。我们知道没有提示消息，任何人都可以访问私人组/类别，但在我们的用例中这不成问题，因为它们不是“秘密”组/类别，它们是私有的，只是为了将它们作为讨论课程主题的专用空间分开。
要求学员将话题加入书签并不容易，但后者建议听起来是我们现在唯一的选择，也是我们可以立即采取的解决问题的行动。
而且我们现在似乎也遇到了这个问题：https://meta.discourse.org/t/no-sign-in-option-in-the-accept-invitation-page-only-the-signup-form-is-shown/245769，谢谢！
再次感谢您和您的团队所做的工作和支持。
哦，这是一个有趣的限制。所以你有一个 Discourse，有 1000 个房间，任何人都可以访问，但你希望课程成员对特定房间有强烈的归属感。
一些问题：
在这里不使用安全性有什么价值？latest 对于普通用户来说是否只是巨大的噪音？我们还有一个“默认情况下所有类别都从 latest 中隐藏”的设置，这可能很有趣。
侧边栏能否稍微缓解一下痛苦？如果你在侧边栏中有类别，至少它会引起注意。也许邀请也应该允许添加到侧边栏？我不确定？
在欢迎主题中更清楚地说明是否有帮助？要找到你的主页，请收藏以下内容并添加到侧边栏，步骤如下
cc @mcwumbly
为什么不将他们的主页设为主要群组？
我认为我们短期内都必须接受对方的限制。
既然听起来 @gassim 有一个运行良好的系统，我认为提供尽可能接近该系统的指导可能是最好的。继续使用群组来限制对特定类别的访问，并减少来自其他地方的噪音。
我们有兴趣清理邀请系统中的一些粗糙之处，使其更易于维护和理解，并且我预计在此过程中会遇到类似的问题。在这种情况下，我们坚持不依赖邀请链接作为可重复使用的主题链接。
阅读了之前的主题后，我认为最合理的方法可能是这样做：
我刚刚合并了这个修复程序，很快就可以更新您的 Discourse 站点了：
感谢您的理解。
感谢您的关注！
保持私密的房间是为课程参与者准备的。基本上，我们希望这些房间成为一个专用空间，而不影响论坛的其他活动（latest、top 等）。将课程讨论论坛放在私有类别中，并不是因为它们是“秘密的”，而是因为只有选择参加课程的人才需要看到主题和讨论，而那些不参加的人可以像往常一样继续使用网站的其余部分。
感谢您的建议！我还没有在侧边栏上做过实验，但这是我还没有推广侧边栏的原因的自由写作：
我不确定，因为对于参加所有课程的参与者来说，将至少有 50 个主题。但是，我们正在使用 @martin 的建议：
感谢您的建议 @Stephen！但是，主页是为所有成员准备的，我们不希望更改它。课程参与者将参加几门课程，但在每门课程结束后，他们会被邀请继续参与社区。
谢谢！
明白了，但这是管理员的选择，可以设置邀请链接在一定使用次数或特定日期后过期（除了限制为特定的电子邮件地址）。对我们来说，因为我们从不希望邀请链接过期，所以过期日期是 2092 年，使用次数是 1000000（当然，没有指定电子邮件地址列表，因为我们希望邀请链接对任何真正想加入私有类别讨论主题的人保持开放）！然而，现在我看不出当链接在每个用户首次使用后都会过期时，这些选项还能有多大用处。
就个人而言，我仍然认为，如果通过在创建邀请链接时添加一个与上述限制类似的选项来强制执行这一点（默认情况下，邀请链接将不可重复使用，除非管理员取消选中此选项，一旦取消选中，将有关于 Discourse 团队所担心的安全问题的警告），那就更容易了。从我的角度来看，这将使一切都变得容易得多。
谢谢！这正是我们目前正在采取的方法；但是，我们需要更新带有屏幕截图的指南，目前我们仍在等待修复程序，该修复程序将“登录”按钮添加到标题中：No 'sign in' option in the accept invitation page, only the signup form is shown
谢谢 @martin！