At the moment we have these limits in admin:
Maximum number of recipients allowed in a personal message
Post count under which users must pass verification when sending personal messages
Number of personal messages a user may send in an hour
Some sites like to set a limit on the total number stored, which is some ways is quite sensible. Many PM's will only be read once, then just sit there in the db doing nothing useful.
Any thoughts re adding a limit on the total? How about different limits per membergroup?
Unless it's been removed, Admin > Members > Membergroups > edit group > Max personal messages
Been in for as long as I can remember.
Yep, it's there.
I tend always to forget where the h**k it is... lol
It may be useful to have a table in the PM settings page too, it would make it more obvious.
Obvious is good. :D
That's one of the problems with 2.0.x (and earlier): stuff isn't consistently where you'd expect it to be. Really, rather than making another table, would it be possible to just have all that stuff in one place?
So, the PM settings page would do all the PM settings, just like it says on the tin. :D
I meant a table in the HTML sense of the term:
<table>
<tr><th>group name</th><th>max number of PMs</th></tr>
<tr><td>regular members</td><td><input type="text" value="" /></td></tr>
...
</table>
in the PM settings page, where all the membergroups are listed along with the maximum number of PMs they can store and where you can change all of them at once without having to edit the membergroups. ;)
Of course if you don't like a table it's fine, we can use something else. :P
Ok gotcha. Something along those lines sounds good. Can be marked up any old way we like.
So you mean move those settings out of the membergroup shiz, and just have them on the PM settings page, so they're only in one place, and it's the place you'd expect them to be?
If that's the short version, I'm up for it. :D
A lot of the problem with 2.0 (and to a lesser degree with 2.1 but from what I've seen it's still an issue) is that it was built for developer convenience rather than end user convenience in a lot of places - e.g. the whole Admin > Themes and Layout > Member Options area. That's straight up dev convenience (for per user settings at least) rather than a meaningful reason to have per user per theme settings.
Okay, I was looking around and:
the "enable reporting of PM" is under "general"
all the others are under "anti-spam".
Now, I don't know you, but the first thing I tried was "forum" to search for PM settings.
Okay, maybe forum is wrong too, but I'm tempted to say that the PMs could deserve a menu entry in config > features and options, instead of have the few settings spread around.
Objections?
Again FWIW:
1) We dropped the option of 'enable reporting', it's just 'on'
2) We created a whole top level page - Admin > Members > Personal Messages which covers enabling the entire subsystem (or not), permissions via the inline permissions stuff, settings for drafts etc. (and the anti-spam settings are duplicated here), seems like it might be worth doing something like that in Elk.
So yes, fully agreed on having a page for all the settings in one place, whether you want to make it a sub page somewhere or a top level page. I suppose I should move the per-group caps to that page too, actually... whistle
Yep, yep, that's basically what I was thinking (except for the inline permissions thing that is not a bad idea at all! *grin*).
It's one of those features that was buried in SMF but it works surprisingly well for non-board permissions just like PMs are.
https://github.com/elkarte/Elkarte/pull/628
Sounds good, except perhaps for the dupication of anti-spam settings. I'd be more inclined to link to the relevant section rather than duplicatiing. As long as there's a clear roadmap, it should be fine.
Whatever works, though. As long as it makes more sense than the current setup, it's all good.
Remove things is usually easy (as long as you find them again after a while :P), so I left them there because somehow it may make sense to have them as anti-spam settings, even though I don't like duplication me too.