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.

Comments

berdir’s picture

I 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.

BenK’s picture

Okay, 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

berdir’s picture

Component: Code » Code (pm_block_user)
Status: Active » Needs review
StatusFileSize
new2.52 KB

Ok, here is a patch which removes blocked users as discussed.

Status: Needs review » Needs work

The last submitted patch, exclude_blocked_users_from_autocomplete.patch, failed testing.

BenK’s picture

I'll manually test as soon as it passes the automated tests...

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new2.47 KB

Fixed function name and removed debug code.

BenK’s picture

Status: Needs review » Reviewed & tested by the community

Hey Berdir,

The patch in #6 works great! Everything functions just as expected. This is ready to be committed.

Thanks!

--Ben

berdir’s picture

Version: 7.x-1.x-dev »
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new2.71 KB

Thanks for testing, commited to 7.x-1.x. Attached is a untested port for 6.x-2.x

BenK’s picture

Status: Needs review » Needs work

Berdir,

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

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new2.73 KB

Upsie. The testbot also ignored the patch because of the d6 suffix :)

Fixed the typo...

berdir’s picture

Status: Needs review » Fixed

Commited.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.