Hey Berdir,
In my testing of "User Blocking Rules," I did notice one thing that is either a bug or a feature request. Basically, if a rule is set at admin/config/messaging/privatemsg/block to prevent sending to a particular role, then users of that role should not show up in the "To" autocomplete field when sending a new message.
Here's a use case: The site admin may want to prevent users other than site administrators from sending messages to regular authenticated users (such as if Private Messaging is being used for an admin notification system). This rule can be set up, but then other users will still see authenticated users listed in the "To" autocomplete (even though they will be prevented from sending to them). This could get cumbersome for sites that have tens of thousands of authenticated users. Also, the site administrator may not want to use all authenticated users on the site to show up in the autocomplete for security reasons.
So here's the question: Would it create a lot of overhead and performance issues to first check who is permitted to show up in the autocomplete?
Also, we have the issue of individual users blocking other users: It would be better if users who are blocking you didn't show up in the autocomplete, but I'm wondering about the overhead issues of having to check if you've been blocked by anyone when writing a new message.
What do you think?
Best,
Ben
P.S. Do roles who do not have "Read messages" permission show up in the autocomplete? I wasn't sure about that one.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | exclude_for_d6_2.patch | 2.73 KB | berdir |
| #8 | exclude_for_d6.patch | 2.71 KB | berdir |
| #6 | exclude_blocked_users_from_autocomplete2.patch | 2.47 KB | berdir |
| #3 | exclude_blocked_users_from_autocomplete.patch | 2.52 KB | berdir |
Comments
Comment #1
berdirI agree that we should block both based on roles and single blocked users. That shouldn't be that hard I think.
However, based on permissions is way more complex, because it works the other way round. You're only not allowed to read private messages if you don't have a role that can read. It is fine to have a role that can't. So I guess the query would become rather complex.
Comment #2
BenK commentedOkay, sounds great. We'll block based on roles and single blocked users, but we won't worry about blocking based on permissions (since the site admin has some control over this anyway through roles that have or don't have the permission).
I'll be ready to test whenever you have something...
--Ben
Comment #3
berdirOk, here is a patch which removes blocked users as discussed.
Comment #5
BenK commentedI'll manually test as soon as it passes the automated tests...
Comment #6
berdirFixed function name and removed debug code.
Comment #7
BenK commentedHey Berdir,
The patch in #6 works great! Everything functions just as expected. This is ready to be committed.
Thanks!
--Ben
Comment #8
berdirThanks for testing, commited to 7.x-1.x. Attached is a untested port for 6.x-2.x
Comment #9
BenK commentedBerdir,
Applying the patch in #8 for D6 resulted in a White Screen of Death. Here's the error message that was in my logs:
PHP Parse error: syntax error, unexpected ')' in /Users/benkaplan/git/drupal-6.17/sites/all/modules/privatemsg/pm_block_user/pm_block_user.module on line 325
--Ben
Comment #10
berdirUpsie. The testbot also ignored the patch because of the d6 suffix :)
Fixed the typo...
Comment #11
berdirCommited.