Message quota

+1 from me, our private message table is currently close to 10mb.

Just found this by accident - still a good idea I think.

Moving to HEAD.

Saying that, I have never know a user who is happy to lose old messages, or be faced with a restriction notice saying the user cannot send more messages.

Message quota functionality is a great idea but is something that should be worked on later after we have the core features working and officially released.

-Paul

nbz, it should be configurable of course - I have some users with thousands of messages just to themselves, and these are the same people who managed quite well with a 2mb hotmail quota for years. I just went to the last page of my issue queue and found this old feature request by accident, have a much bigger server now, so it's less of a concern.

Attached is a first working version. It should work but is not yet finished, I'm especially unhappy about the wording of the admin screen and the error messages (as always ;) ). For, example, how should we refer to the messages a user has? That part is still a bit a mess, the code should however should be pretty clean.

Features:
- Can be configured to count either threads or messages. Threads means that a user can still answer/recieve responses in existing threads but he can't create new threads when the limit is reached.
- Send quota: Allows sending limits per time (for example, a maximum of 5 messages in 5 minutes). The defined time is always considered as "backwards from now", what means that a user could write (with the previous example) a message per minute endlessly.
- Recieve quota: Allows to limit the amount of messages/threads a user has. If the maximum is reached, the user can't recieve or send messages/threads anymore.
- Allows rule-based exceptions for both quotas, the highest value a user has in his roles is considered.
- Displays a short info at the end of the list which tells a user how much of his quota is used. Format of the hook is already converted to use form_alter, as changed in #348907: Per thread/Multiple thread actions.
- If the recieve quota is reached, a dsm error message is displayed in the message list.
- If a message is sent to a user which recieve quota is reached, a warning message is displayed and the user is removed from the recipient list. If no valid users are found after the check, the message is not sent at all.

Current issues:
- We (as in I ;) ) need to find a better way to pass validation messages and stuff around. Currently, this modules displays a dsm warning in the validate hook, which is not good. See #375999: #288183 followup: Developer friendlify privatemsg_new_thread API.
- Relies on [#348909] for the stuff that is displayed in the list, should work except of that
- Bad wording and naming conventions (quota, threshold, amount, some_other_insane_word_I_used, ..)

Some screenshots.

No, I'm not going to make a video, it isn't fancy enough :)

Looking at the second image, should be send/recieve, not just send.

Just wondering over how the blocking is done in this message via the validate function and the separate hook_privatemsg_block_message that is used in the pm_block_user.

Do we need to keep both methods? Is one recommended over the other?

(I can see a problem with multiple dsm's about the author exceeding the quota when using the hook...)

A additional thought:

The rate of sending new messages (best to limit 1 message per x seconds instead of x*5 of x* 5 seconds - simpler to understand for the end user) and also the max number of recipients per message should IMO be controllable in the main module and not rely on a submodule.

This would also allow the quota module to just be a quota module.

Hm..

Actually, I never thought about doing it with the block hook, I just started with validate, I didn't connect it with block at all. And, did you see #376023: #288183 followup: change hook_privatemsg_block_message to work on multiple recipients already? litwol asked if we can replace the current block hook with _validate, so that modules implementing it could save some queries by checking all recipients at once.

Downside is, with the current implementation, it needs a little trick to remove the recipients from the list (by saving the id's in a global variable and deleting them in presave_alter.

I don't really have an opinion on that, if we keep the block hook, I'm fine with moving the recipients part of the validation to the block hook.

privatemsg_flood_control? i think its out of scope of the core module.

@nbz
No need to put that in the main module imho.

What about using 1 as the default value to make it easier to understand ? I like the more flexible approach more, just because I'm sending 2-3 messages in a short time doesn't mean I'm a spammer, or trying to flood the system ;). Technically, there is no difference between the 1 vs n messages test.. the module simply counts the messages there were sent in the last x seconds by that users.

As I said above, the wording is bad, maybe there is a better way to explain it.

Message quota for drupal 5?

Please don't change existing issues, it is very unlikely that any active development for 5.x will be done.

Just added a 'Messages per-thread' setting for this, which forces messages to be split into a new thread when that thread has a given number of messages. The point is to make the old school, one message per-thread, style of the Drupal 5 Privatemsg possible again.

Had to use a hook_form_alter(), as $message isn't passed by reference into hook_privatemsg_message_validate() yet. This should be refactored after #398916: Remove hook_form_alter in favor of a more flexible privatemsg_new form goes in. :)

Thought it would be easier to provide a whole new copy of the module than a patch, but will provide patches to any further changes if people prefer.

The problem with hook_form_alter is that it ignores messages sent by the api functions.

However, you should be able to use the privatemsg_message_presave_alter hook, as you are not actually validating anything but change the message (remove thread_id, if available).

You could maybe add a setting to switch between "create new thread" (presave) and "deny to send message" (validate).

Thanks for the advice berdir, here's an updated version. :)

You might want to use GROUP BY in your count messages query, because pm_index might contain multiple lines for the same uid, when the user has written some messages himself. (currently, this might change...).

Other than that, your changes look good.

This can now (probably) be changed to use the block_user_messages since #376023: #288183 followup: change hook_privatemsg_block_message to work on multiple recipients has been comitted.

I hate to sound unappreciative and cranky but I dont think quota is a good word to use in this context. Everyday people do not use "quota" in this manner. I can just imagine the mountains of users who are going to send me help messages over the alert that their quota is reached. Drupal wording is such an endless frustration...

To most people a quota is something they need to fill at their jobs, if they're familiar with it at all, not a maximum limit for their inboxes. I know there are language differences in drupal developers that lead to funky naming because of a lack of knowledge of colloquial usages, but... common guys.

/headache

Why not use "Your inbox is full" like 99.99% of everyone else.

@highvoltage, no harm done.

What words do you recommend we use for this ?

There are various use cases:
1) inbox empty
2) inbox full
3) inbox % used.
4) user X cant receive messages because his box is full
5) You are viewing your own box and your limit is reached, you are notified to delete some messages...
6) ????

Please brainstorm various use cases and end-user meaningful ways to describe them. I will certainly include it into the module if the suggestions make sense.

Cheers.

I can only repeat myself:

Attached is a first working version. It should work but is not yet finished, I'm especially unhappy about the wording of the admin screen and the error messages (as always ;) )

This is a first _technical_ preview, I am not a native speaker and I am only familiar with the "technical" english, because that's what I use. So, I am open for open for wording suggestions, also keep in mind that there are different areas: "Public/Normal" user interface, Administration user interface, Code. Not every area needs to use the same word.

Update: While I'm glad about every feedback I can get, what really helps are exact improvement suggestions, something like a list of "My ugly text" => "Your suggestion".

Yeah, sorry about not adding something more useful than the complaint x_x. Keeping the language dead simple is the way to go for alerts presented to users. As long as they know that the inbox is being referred to and how it's current state affects what they want to do(sending or recieving), it should be fine.

A few examples:

-Your inbox is full, you must delete some of your existing messages before you can receive new ones.

-Bob's inbox is full, he cannot receive new messages.

-Your inbox is 46% full.

-You have reached your send limit, please wait *insert time* before trying again.

Or to go even further you can add an explanation as users might become frustrated by this particular setting...

-To prevent spam, the administrator has set a send limit of five messages within ten minutes. Please wait *insert time* before trying again.

I also suggest 2 options:

-msgs older than X days could be removed automatically (system wide option or user option)
-the user could opt to lost the oldest msg if a new one was sent, in that case the sender wouldn't get a limit msg stopping him to send it

@Afiejo - the problem with both of them is that a user will not be consenting to the removal of the messages.

As for the latter option, I can see it causing problems where you can delete an important message (maybe even before its read?) from a user's inbox by sending enough spam.

Hello @all,

with the new dev version from privatemsg it seems the quota - module don't work anymore.
Can anybody tell me whether the module gets an upgrade.

Thx
Tomtom

subscribe

couple months since this was talked about... might this make it in for 1.0? Is there anything that needs to be finished?

I also noticed that the message quota no longer works with the dev version of privatemsg.

Subscribing.

I just finished redoing a "quota" module for a client that limits the number of messages a user can send over a period of time and gives a warning message to users when they access the message form about how many messages they have left.

This was before I realized how extensive Berdir's module was already (oops), so it's not based on any of that code :( , but I think it's solid and gives the most common features requested for this type of module, to limit spam.

Hah ;)

I will try to reroll this soon, however, I *need* help with that. Not with the technical stuff, I can handle that, but with the user facing (and probably also documentation) strings. See #21-24 for a start.

Oh, and if you want to help, please go through the patch and propose exact changes.

Example:
- Instead of "'Enable Recieve Quota of messages'" I suggest to use "some better string".
- ...

I gave it a shot on the admin interface. The string replacements make more sense to me at least, and I have the feeling I'm a bit more "average joe" than others here.

I gave up on the "Select a timeframe" description though. It's been a long day and I couldn't quite wrap my mind around that one. Perhaps if I smoke a joint and stare at if for a half-hour it'll come to me.

Oh something popped into my mind. I think we should allow users over quota receive messages, but they will simply not see those messages. ha! I think that users will be *very* enticed to delete old messages when they are aware that they have X messages they received but may not be read. Nothing like a harmless bait. This solves the problem of *whether sender should be blocked from sending when receiving inbox is full* or *whether mesages just get undelivered*, etc.

Yes so simply receiving message but not allowing it to be viewed until inbox quota limit have been resolved should be an easy median between various solutions... Especially if we make the *quota is full* resolution configurable in admin (prevent receiving, receive but dont allow reading, prevent receiving and notify sender, etc...)

What does this mean for database storage? On database level it means that we store more messages, yes and that is inevitable. However i will strongly argue that physical storage is nearly free today and especially when talking about storing text. Performance *may* be negatively impacted, but we take great care to be consistent on performance and if extra messages introduce obvious slow performance to this module then we will surely address it immediately.

As a user, I would have no problem removing a batch of old messages...
...if those messages could be easily forwarded to my e-mail account first.
And I would be putting to use my space on Gmail :-)

I think a configurable quota/limitation setting would be nice, but I don't think I would use it except as a safety device to keep people from spamming. In that sense, I would use some sort of time limit per message sent. For example, you can only send one message per every five minutes.

Re-rolled with the text string changes of #33 and and also did a few replacements, for example quota => limit in some places.

I did not test it very well, but send/recieve quotas seemed to work.

How difficult would it be to limit the number of recipients a user is allowed to send a single message to?

Sending a message to all of the users of a site, with a single click of a mouse seems like a spammer's dream.

Another user needed my module to limit the number of messages a user can send per period of time, so i cleaned it up a little and posted it to d.o
http://drupal.org/project/privatemsg_limits

It doesn't look like to much of Berdir's work and mine overlaps since it looks like the patch focuses on limiting inbox size, not number of messages. This module could also be used to set a maximum number of recipients per post as well by setting the time period to zero, and a limit to what ever you wanted the per message limit to be. I'd appreciate any feedback since I'm planning to user this on a clients site. If you'd like to work this back into privatemsg core, just let me know.

@frankcarey
I haven't looked in detail at your module, but message_quota supports sending quota/limits too, in messages (or threads) per timeframe, as your module. Only difference seems to be that yours can have a configurable warning/output level.

I see that I have to look more closely at the quota module code as well. When i was creating limits, I was wondering if it would make sense to make more of a limit/quota api so that custom limits could be more easily added by hook or overridden. I have this partly setup by passing a $limits object in and out of my functions, but it probably needs more than that... thoughts?

Not sure...

However, I am pretty sure that we should merge our modules together, feel free to re-use my code. I will probably make a patch against your module to incorporate my additional features sooner or later, but I don't have much time at the moment.

I will probably release my other sub-modules (rules integration and attachments) as separate projects too, the chances that they will be commited soon are rather small, especially for attachments, which can probably be deprecated in D7 (fields + filefield in core... :)). And maintaing a module in a issue hurts.. physically ;)

agreed. I'd be happy to give you CVS access to the privatemsg_limits project, which would make collaboration that much easier, sound good?

subscribe