Personal message rate limit also limits "Something Else" flags

Reproducing the problem

  1. Get a test instance so that you don’t break an existing community.
  2. Set max personal messages per day = 1. (Default is 20. I’m not sure what 0 means for this setting, so I’m using the next best thing.)
  3. Impersonate a non-staff user. (As an admin I didn’t see the problem. I’m guessing it’s because staff are not subject to this rate limit, but I haven’t looked at the code to be sure.)
  4. Send a test private message from the account you are impersonating to somebody else. (I sent it to my own account.)
  5. Flag a random post with the “Something Else” reason. (From what I can tell, other flag reasons don’t exhibit the problem.)

You should get a popup saying:

An error occurred: You’ve reached the maximum messages allowed per day. You can create more new messages in 23 hours.

Why it matters

There are several relevant settings:

  1. PM threads per day. (Default 20)
  2. Flags per day. (Default 20)
  3. Flags per day multiplies per trust level. (TL2 => 1.5, TL3 => 2, TL4 => 3)

As a result, use TL3 users can start up to 20 PM threads in a rolling 24-hour period and flag up to 40 posts. However, flags that use the “Something Else” reason count against both the PM thread limit and the flag limit. Since there is no TL multiplier for the PM limit, it’s impossible to increase the rate limit just for trusted users.

Perhaps more importantly, the message doesn’t seem related to the action the user took. It’s not obvious that one particular flag reason would start a PM thread. To see this confusion in real life, see these threads:

  1. Maximum messages per day?
  2. Reached maximum messages….again

After investigating today, I now can suggest not using the “Something Else” reason if you run out of PM threads in a day. But that’s not ideal because it will discourage some users from adding necessary context to their flags. I’ll probably just increase the PM thread rate limit and hope nobody figures out they can start spamming other users.

Possible solutions

  1. Don’t count PM threads generated by the system against a user. So if I flag a post and the system helpfully turns it into a PM thread with the moderators, that shouldn’t count against my limit. For flags, only the flagging rate limit should apply.
  2. Fix the message so that users can self-diagnose the problem. I don’t have pithy copy to suggest, but it should be clear the problem is flagging with “Something Else” rather than other types of flags. I’d leave off any indication that this is related to PM threads unless its carefully explained. It’s just getting too much into the guts of the system for the average person.
  3. Add TL-based multipliers to the PM thread rate limit. I honestly think 20 is enough in all but the most extreme situations. But if flags eat into the limit, I’d want to give trusted users at least as many PM thread starts as regular users.
7 Likes

Hey @sam, you :heart: this and it’s been a month (and I finally got the site upgraded to 3.1.0.beta3). I was just checking in to see if the long-awaited upgrade was going to include a fix for this, I thought I remembered seeing a commit about it, but I don’t see anything here.

I like the idea of fixing this, but nothing has been slotted yet. Decoupling sounds like the right solution.

2 Likes

Hi,

I have a fix for this bug. But, I’d like to discuss my solution before putting the PR up.
It’s pretty straightforward, the new private message is set to belong to the system user and the actual user is made a recipient of it instead of initiator.

One thing worth mentioning: the user will receive his own message from system in his inbox.

Any thoughts?

1 Like

This would be a fantastic improvement all around for Discourse. Even with the default of not allowing TL0 to send PMs, suddenly allowing TL1 to send a bunch of different new PM threads is a low-grade PM spam attack just waiting to happen. Or, the PM rate limit can be set to something very low, but that would be untenable to also apply that same rate to trusted users >= TL2.