META: Permissions can be configured so that users receive messages that they cannot read

Hmm, me too. I'm surprised that there hasn't been any more discussion on this, perhaps it has been or will be resolved in 2.x ?

"Un-receivable" messages just stack up in the database with no way for the recipient to receive them and the sender may never know whether it has been read (I don't go for activating the option for a sender to see when their message has been opened). I suppose every site has a different requirement however I'd have expected an option that by default a user without permissions cannot receive messages, and would get the same "xxxx does not accept private messages" notification as when attempting to send a message to a privatemsg qualified user who has turned off privatemsg in his/her profile.

how do you suggest this to be solved?

I can imagine it done in the following way: when a user that cant view a message receives a private message, he wont be notified of it and he wont even see a message in his box. to me however this doesnt sound like a good idea. if i was to receive a message and i couldnt see it, i would seek site administrator's advice on why that happened: perhaps he was blocked, or perhaps it was a bug.

on the other hand, if a sender sends a message to a user that can't view it, perhaps the sender should be notified that the recepient did receive the message but will not be able to view it?

This needs more thought on how this will be handled as this problem seems to be above trivial complexity.

I think of two important things:

For the user: they should be notified immediately that the message cannot be sent
For admin: it should never go to database (when a message will not be received)

In both cases, as I touched on above, it should be identical to when I try to send a message to a user who can use privatemsg, but has checked the profile setting not to receive private messages. As you know, in this case, the message never gets sent (or stored) and the sender gets an instant notification "xxxx does not accept private messages".

Implementation? My take is (adapting the privatemsg_new_validate function) to add a check that the user (or user's role) has an access permission for privatemsg? That's to say append to the "$recipient->privatemsg_allow" check (i.e. User can use privatemsg? AND "Allow private messages" is checked in user's profile?)

The error message would need to be modified. I propose making the standard message suitably general. Something like: "You cannot send a message to this user" or "Your message could not be sent, [user] has either opted not to receive messages or does not have sufficient privileges".

I just ran into this on D6. I think, at a minimum, not notifying users they have a new PM when they don't have access to read them would be good. Obviously not a whole solution, but it's a start. :)

Michelle

Considering that D7 is almost on the horizon, i am reluctant to accept anything towards the D5 branch. people should switch to d6 asap. any further work should be done on d6 and forward.

That's fine by me. This was just the only issue on the subject I found while searching your queue. And it is still an issue in D6.

Michelle

I have modified the patch in #344339: You have blank new messages block to cover comment 6.

I am keeping this issue open as the other issue is still a valid one and bares thinking about.

We do have the ability to block messages to users - Maybe plug into that and check if the user is allowed to read messages?

This would need to be in the core privatemsg module and not as a separate thing in block_user_messages IMO.

So it appears it is possible that users can receive messages that they cannot actually read. This sounds like a bug to me.

added issue summary

edited summary

Responded in the various issues. Not sure about the need for this meta issue, it's quite confusing. I'd rather have a single issue with a combined patch except the mail stuff, that's a separate problem.

All solutions consolidated into this thread: Closing as a duplicate and combining into the patch over here: https://drupal.org/node/1928502

add proposed solution