您好,我们最近在我们的实例上实施了 Reaction 插件,我们的一位成员报告说他达到了“每日最大反应次数”上限 (Site Feedback Roundup - July 15 - #4 by anon46315158 - Site Feedback - Katalon Community )。他提到,在更改反应/添加反应大约 10 次后,他看到了模态框。
所以我的问题是:
我们能否完全删除“每日反应限制”?或者,
调整每个 TL 的限制?(在 site settings 中没有看到这个设置)
谢谢
2 个赞
这个看起来像是“你发送了过多的点赞/表情反应”的警告,而不是“你没有点赞了”的警告,因为你只需要等待很短的时间就能再次拥有它们。可能需要更新消息文本。
我不认为表情反应每天也有像点赞那样的数量限制?(每天最多点赞数)
4 个赞
嗯,有意思,您是否知道用户在进行/更改反应之前需要等待的每次反应之间的间隔/持续时间?
另外,这个间隔/持续时间是否会随着他们信任等级的升高或降低而增加/减少?
另外,我找到了编辑该模态所需的查询:js.discourse_reactions.reaction.too_many_request
我将把每天最多点赞数增加到 100 以确保万无一失
我认为它很短,所以你必须在几秒钟内点击几个才能触发冷却时间。如果你以通常的方式阅读帖子并做出反应/点赞,你根本不应该看到它。我不认为信任等级有任何影响。如果用户反复点击反应来添加/删除/更改一个,那么这很可能就是他们遇到的(以及原因)。我认为这主要是为了防止垃圾信息的功能,以阻止人们在不阅读任何内容的情况下添加大量内容。
我认为我们可能需要为所有人更改该消息,所以如果发生这种情况,我会通知你,以便你可以重置为默认值。
如果你能避免更改基础点赞数,我会这样做,因为这会影响相关的徽章。但是调整点赞乘数可以很好地提供更多的点赞,而不会增加获得“缺爱”等徽章所需的点赞数量。
嗯,我不知道我们可以这样做。在“站点设置”中,我应该去哪个部分来调整点赞乘数?谢谢。
如果您使用管理员设置搜索并输入 additional likes per day multiplier,它应该会显示所有这些设置。 它们位于速率限制部分,还有一些用于编辑和标记的其他设置。
2 个赞
正在考虑将模态文本更改为以下内容:
哇,等等!您之所以看到此弹出窗口,是因为我们注意到您反应帖子(或帖子)的速度非常快。何不休息一下,在 %{time_left} 后回来?
不过,我认为在决定这是否是一个具体解决方案之前,我需要等待其他 Discourse 成员的意见
@Vu_Tran_Nguyen 供您参考
1 个赞
我只是想再次确认一下,看看“Reactions”是否与“max like”设置相关联。您截图中的触发方式和非常短的冷却时间让我觉得可能弄混了,但我还是想确认一下。
2 个赞
您好,Albert:
请保留默认的反应限制设置。我会考虑更改为更积极的措辞,例如:
感谢您的热情。我们相信原创帖子的作者会喜欢您所有的点赞和反应。请在 %{time_left} 后回来,继续鼓励社区用户。为所有的积极点赞!
1 个赞
FWIW 原始文本应为“您反应太快了,请在 %{time_left} 后重试”。
2 个赞
这似乎在 Discourse 中也是如此,当受到速率限制时,它会告诉我“您已用完点赞次数 - 50 秒后再试!”
simon
2022 年7 月 27 日 22:44
13
我认为这里的问题在于,当用户通过反复添加和删除表情符号来触发速率限制时,以及当用户选择了网站上用于“点赞”的表情符号并达到了每日点赞上限时,使用了相同的文本字符串(js.discourse_reactions.reaction.too_many_request)。该上限由 max likes per day 网站设置确定。
我通过执行与您用户类似的操作,成功触发了您用户遇到的问题。触发该问题需要付出一些努力。我认为很少有用户会遇到它。不过,为此情况显示的错误消息并不准确。用户并未超出他们每日的表情符号(“点赞”)上限。他们只是触发了 Discourse 的速率限制,该限制会在用户连续执行相同操作过多的情况下触发。我认为我们需要一个单独的错误消息来处理这种情况。
3 个赞