Thanks for this great module. I noticed the following bug in privatemsg_limits.

Privatemsg settings:

  • Limit the total no. of messages/conv. a user can send
  • What should be limited: conversations
  • Set time period: 1 week
  • Maximum limit by role: role "limit2": 2

If a user sends new private messages first, they can contact two new users per week as follows:

  1. User A with role limit2 sends a private message to User B.
  2. User A with role limit2 sends a private message to User C.
  3. User A with role limit2 replies to a private message from User D.

However, if a user replies to new private messages first, those replies reduce the number of new users they can contact:

  1. User A with role limit2 replies to a private message from User D.
  2. User A with role limit2 sends a private message to User B.
  3. User A with role limit2 sends a private message to User C. -> This fails with a "you have exceeded your sending limit" message.

This implementation is inconsistent. A reply to a private message should not affect the limit depending on whether it is before or after the user has sent other messages.

Files: 
CommentFileSizeAuthor
#5 privatemsg_fix_inconsistent_limits_1514286-5.patch742 bytesptmkenny
PASSED: [[SimpleTest]]: [MySQL] 4,913 pass(es).
[ View ]

Comments

Title:Limiting the number of conversations leads to strange behaviorLimiting the number of conversations leads to inconsistent behavior

I examined the code to try to find the source of this issue, and it appears that to get the limits, _privatemsg_limits_get_sent() makes a SQL query that looks for all messages that the users have sent in the past interval.

However, replies should be excluded from this query if "conversations" are being limited instead of "messages."

Is there any way to check if a sent message is an original message rather than a reply, and then to exclude that from the count returned by_privatemsg_limits_get_sent()?

Yes, the first messag is the one where mid = thread_id.

Not sure what is the correct behavior here, the question is if the limitiation of conversions a user can *start" or that he can participate in... Agreed that the current behavior is inconsistent.

Thank you for the fast reply!

My impression after reading the module's interface text was that it would limit the number of conservations the user can "start," not "participate" in.

Under "what should be limited":
"Do you want to limit the number of individual messages a user can send, or limit the number of message conversations a user can initiate? An exceeded conversation limit will allow users to still write individual messages in existing conversations, but not start new ones."

Even if the user has not replied to a message, if the user has received a message, I think it should be considered an "existing conversation."

Also, I think "start" is a much more likely use case than "participate." On my site, I am attempting to restrict the number of conversations users can start in order to force users to think more carefully about who they want to contact. I know of several sites which work in a similar way, but I cannot think of a site (off the top of my head) that restricts "participating" in conversations.

As for determining the first message-- where could I add this as a requirement? _privatemsg_limits_get_sent() calls _privatemsg_assemble_query(), but with the large number of parameters I can't find where to begin to insert such a check.

Version:7.x-1.2» 7.x-2.x-dev
Status:Active» Needs review
StatusFileSize
new742 bytes
PASSED: [[SimpleTest]]: [MySQL] 4,913 pass(es).
[ View ]

Now that #147420: Add tracking for replies has been committed, I was able to write a patch that fixes this in a very straightforward manner and makes the behavior consistent (only new messages are counted, not replies).

Issue summary:View changes

fixed ul tag