500字符的“拒绝原因”限制太小

用户体验
,
1

当通知审查新用户申请到我的论坛时，如果我使用“删除用户”选项拒绝该申请，并且在过程中选择包含电子邮件说明其申请未获批准的原因的选项，我现在会收到“422 错误”作为响应。

如果我省略说明，我就可以像以前一样删除用户。

论坛生成的电子邮件通知给注册用户，否则仍然正常工作。

当前安装的 Discourse 版本是 3.2.0.beta5-dev

论坛错误日志与此发生日期（今天）对应的日志如下：

5
弃用通知：`SiteSetting.min_trust_to_edit_post` 已弃用。请使用 `SiteSetting.edit_post_allowed_groups` 替代。（将在 Discourse 3.3 中移除） 在 /var/www/discourse/app/models/co
1:19 pm
15
弃用通知：警告：email 参数已弃用。所有发送到此路由的 POST 请求都应使用 base64 严格编码的 email_encoded 参数发送。已收到 email 并
1:37 pm
无法处理电子邮件：Email::Receiver::AutoGeneratedEmailError 收到：来自 smtp-mx-server-8.servers.netregistry.net (未知 [202.124.241.69]) 通过 nz-mail-receiver.localdomain (Postfix)
1:37 pm
无法处理电子邮件：Email::Receiver::NoBodyDetectedError 收到：来自 EUR04-VI1-obe.outbound.protection.outlook.com (未知 [104.47.14.50]) 通过 nz-mail-receiver.localdomain (Postfix)
1:39 pm
2
ActiveRecord::RecordInvalid (验证失败：拒绝理由过长（最多 500 个字符） app/models/reviewable.rb:362:in `transition_to' app/models/reviewable.rb:335:in `block in perform
1:51 pm
2
处理异常时出错，应用程序中间件：ActiveRecord::RecordInvalid：验证失败：拒绝理由过长（最多 500 个字符）
1:51 pm
235
Sidekiq 消耗内存过多（使用：557.11M）用于“nzarchitecture.net.nz”，正在重启
1:54 pm
38
弃用通知：`SiteSetting.min_trust_to_create_tag` 已弃用。请使用 `SiteSetting.create_tag_allowed_groups` 替代。（将在 Discourse 3.3 中移除） 在 /var/www/discourse/lib/guardia
2:06 pm
33
弃用通知：`SiteSetting.min_trust_to_edit_post` 已弃用。请使用 `SiteSetting.edit_post_allowed_groups` 替代。（将在 Discourse 3.3 中移除） 在 /var/www/discourse/lib/guardian/
2:06 pm

我不确定此问题是在哪个 Discourse 软件版本首次开始出现的，因为我收到的申请不多，而且很少需要拒绝，但肯定的是，我以前从未遇到过这样的问题，而且我之前在给申请人的拒绝通知中也使用了相同的粘贴消息。

我看到提到了“拒绝理由过长（最多 500 个字符）”，我的标准拒绝理由文本确实超过了 500 个字符——但这似乎以前是有效的。

我认为解决这个问题很重要，因为为任何拒绝提供完整且令人满意的解释是对潜在申请人的基本礼貌，特别是当申请显然不是恶意动机时（如果他们不符合预期的会员资格标准，但并非明显是机器人、营销人员或其他“不良行为者”）。

如果还想为可能想重新申请的人提供建议，在 500 个字符内做到这一点很困难。如果需要，是否有办法增加字符限制？

这个问题在其他地方被提出过，但我想重申这个请求（如果任何开发者看到此信息），即我们还应该有一个可编辑的标准“拒绝理由”下拉列表供选择。

3 个赞
3

我认为最近对其中一些文本字段设置了限制，尽管在某些情况下这些限制是合理的猜测。我会看看这个是否可以提高到更高的数值。您知道需要多少字符吗？

如果您能加入一个现有的话题，这将有助于表明这是一个受欢迎的请求，并且通常可以提高其优先级。 :+1:

3 个赞
4

您好，感谢 @JammyDodger，我当前的拒绝原因文本有 2211 个字符长，因为它包含针对一些需要一些细微差别的场景的建议（这是一个相当专业的论坛）。

暂时忽略下拉原因列表的建议，而不是让这个原因默认为空字段，能否将其默认设置为使用预定义的文本字符串？并提供一个复选框，允许在需要时临时使用空字段作为自定义文本选项的替代？

将尝试查找单独的请求线程。

1 个赞
5

是的，没错，大约 9 个月前我们为此添加了一个数据库级别的限制：DEV: Set limits for text fields in reviewables · discourse/discourse@783c935 · GitHub

目前没有可能在每个实例的基础上覆盖它。我很乐意稍微提高限制，也许提高到 2000 个字符，但首先我想看看在实际使用中出现这种情况的更多案例。目前，缩短该消息（也许添加一个指向包含其余内容的帖子的链接）对我来说是合理的。

我认为我们应该改进用户界面，以便将错误消息显示给输入超出限制的文本的用户。

8

如果网站需要登录，已发布的页面可能会非常适合。即使设置为需要登录，也可以让匿名用户看到它们。

2 个赞
9

谢谢大家。我已经这样做了，尽管我更希望消除申请人已经感到有些恼火时所需的额外步骤——尤其是因为电子邮件应用程序通常会默认阻止打开电子邮件中收到的网址。

我希望不要不必要地激怒或疏远任何后来可能成为可行论坛用户的人。

而且我仍然希望不必每次都手动复制粘贴此消息。

1 个赞
10

我个人没见过会这样做的电子邮件应用程序，这似乎是一个奇怪的默认设置。

11

我自己的 Microsoft Outlook 应用就是其中一个例子。这种行为似乎受到它与收到的消息关联的信任级别的影响。
新用户/申请人会触发自动邮件回复，如果用户还没有将发送域添加到其受信任发件人列表，这封邮件可能会显得有点像垃圾邮件——而这一步似乎比新用户可以依赖的操作要多一些，特别是如果他们还没有被实际接受为用户。

我已经尽力最大化我的邮件域声誉，但我的论坛发送的一些消息仍然会进入某些收件人的垃圾邮件文件夹——虽然它们仍然可以在那里阅读，但链接总是被禁用。

14

我这里遇到了同样的情况。我至少需要 1200 个字符才能提供链接和联系信息。这种情况有点烦人。另外，能够分段也会让它看起来不那么死板。谢谢。

1 个赞
16

我在这次提交中将限制提高到了 2000 个字符，并修复了错误消息的显示 :slight_smile:

3 个赞
17

感谢 @martin，但它在我的托管帐户上对我来说还没有用。我仍然收到错误。我的字符数不到 1100。谢谢。

1 个赞
18

哦，对了——有趣的是，尽管收到了错误，但电子邮件还是正确发送了。不过用户没有被删除。我想知道这是否意味着我昨天向同一个用户发送了大约 20 封电子邮件？

2 个赞
19

抱歉，我没意识到您是托管客户，如果您私信我网站名称，我今天就会部署更改。

这很奇怪，我会仔细检查。昨天我在处理更改时没有注意到重复的电子邮件。

3 个赞
20

确实，即使出现字符限制错误，电子邮件也会发送 :fearful: 我现在正在处理修复。

4 个赞
21

修复已完成：

我将很快部署您的网站，感谢您发送过来。

2 个赞
22

此主题已在 3 天后自动关闭。不再允许回复。