Disable private message receipts

By this do you mean private messages from anyone or just from a selected user?

If selected user, then the "block user messages" module does that. but in general there is nothing atm.

I meant in general. I didn't think there was, but that line in privatemsg.module gave me hope. :)

I'd be willing to write the feature if we can figure out what would make the most sense for other users.

I'm thinking an enhancement to the privatemsg main module makes the most sense. If the "receive messages" setting is off for the user, it could override any other setting for "message me" type links, etc. The key would be to not break override functionality like described in #267814: Setting to define certain roles (e.g. staff) which a user cannot block PMs from.

Thoughts?

As nbz said, there is currently nothing like that, but this is easy to implement in a small custom module, you don't need to change privatemsg.module for that.

You just need to implement the following hook: http://blog.worldempire.ch/api/function/hook_privatemsg_block_message/1*.

Create a table where you store which user is allowed to write to which, add a new permission "write a private messages to all users", add a way to "mark" users that they are allowed to write you and then check in the block_message hook if $author has the mentioned permission or if $author is allowed to write $recipient.

privatemsg.module will then take care of the rest (don't display send message links, block messages to users which you are not allowed to send and so on).

* That hook will be changed, instead of being called multiple times for multiple recipients, it will receive an array of recipients. See #376023: #288183 followup: change hook_privatemsg_block_message to work on multiple recipients.

Is this a feature that you'd be interested incorporating into the privatemsg module itself or if I write it as a submodule, into the privatemsg family?

If you don't think it has enough value as a feature I'll just write it for us. But if there is enough interest I'll write a more generic version and contribute it back.

I've taken an initial run at this.

The basic semantics of this module are that if you've disabled messages, the whole functionality is turned off. You can't access your inbox or sent messages, etc. Given that approach a couple of issues arose:

1. A way of overriding the privatemsg_user_access function with a hook would be nice. The method I took to hiding the menu tabs isn't generic and is pretty clumsy.

2. I attempted to handle what I could for viewing another user's private messages section, but since the functionality in the actual module isn't working I make no promises.

3. I think that fundamentally this is a feature that belongs in the private messages base module. :)

Attachment	Size
pm_disable.tgz	1.47 KB

Not had a look at the attachment, but have you tried modifying the "block user messages" module? Have an access check in there so that if the recipient cannot read messages, show an error and block the message?

I considered it. But I don't think it makes sense to allow a user to block receiving any PMs and still allow them to send them. And putting code in the "Block User messages" module to stop the sending of private messages as well as hiding the inbox, etc. seemed to change the meaning of that module too much.

The inbox etc will be hidden from a user if they do not have access to read the messages anyway? (well, if it isn't, it should be)

The block user messages check should be to see if a recipient can read the message or not and this can be tweaked for other situations where it may not be a good idea to receive messages to an account that sends them (think of a notification account linked into some rule where no one reads the replies...)

I do now understand what you want, it wasn't clear to me from what you wrote above. I thought you want the opposite of the pm_block_user module, a module that would allow to only allow specific users to write you, a whitelist instead of a blacklist system.

Yes, it probably makes sense to have such a feature in privatemsg.module A few things, from looking over your code:

- You should not try to fix things that are broken in privatemsg.module with sort of an overlay. If you are interested in fixing the read all messages stuff, please contribute to #298502: Better access to another user's messages. The problem with that issue is that it a) currently heavily conflicts with other things, like thread actions and nbz'x inbox patch and b) it is way more complex than just allowing users to see the the list of messages of another users, see me ideas at #17.

- Why not creating your own access function which calls privatemsg_view_access? (For now, adding it to privatemsg.module would make it easier, but that needs some time to get reviewed etc.)

- You should probably add the setting to the user edit form...

- If implementing it as a patch against privatemsg.module, don't forget to add a admin setting to turn that feature on/off.

I finally got around to implementing this as a patch against the privatemsg module. It came out cleaner than as a submodule. This also incorporates the relevant code from #393946: User settings page for the settings page.

Attachment	Size
privatemsg-404044-10.patch	4.25 KB

Looking at the patch, some things I noticed..

- I'd suggest adding either a permission or an admin setting which allows to enable/disable that feature.
- Because of the above, it makes sense to use my proposed user_settings hook. If we wouldn't do that, other modules could simply alter your form.

- Minor coding style issue: add () to the hook name and remove "empty" line

- I'd suggest to move the submit button to privatemsg_user_settings() and rename it to "Save settings" (doesn't need a title, imho) or something like that so that all modules can share that one.

- I think you can remove most of those empty lines in privatemsg_is_disabled and privatemsg_privatemsg_user_settings

+function privatemsg_is_disabled($uid) {
- A simple apidoc for that function would be nice, explain what it does, expect and returns

+  drupal_set_message(t('You have @status private messages.', array('@status' =>$status) ));
- enabled/disabled won't be translatable that way, you need to use a separate t() call.

- Can't we use $user->data to store if a user has enabled/disabled privatemsg? that would save us another table and a additional query on each page request. IIRC, you could something like: (untested, according to http://api.drupal.org/api/function/user_save/6)

And then access it with

- If not, you need to provide a update function which creates your table.

I'm willing to add another permission setting if you feel it's important. I'm not sure I understand your follow up point, though.

I went ahead and rewrote this to use the $user->data field, but the more I thought about it the less I liked it. I agree that we're going to have issues if we don't store the setting so it doesn't have to be retrieved every time, but there are other ways to handle that (hook_user for example). The $user->data design is deeply flawed in my opinion and Drupal should remove it entirely, it violates the modularity of the architecture.

So I ended up reverting those changes and made some other code changes to only look up of the disabled flag once per request.

I also made the other suggested changes. Rerolled patch is attached.

Attachment	Size
privatemsg-404044-12.patch	5.66 KB

Hi

rmjiv - I couldn't apply patch from #12 into Privatemsg 6.x-1.0-rc2, why it's so?

Version: 6.x-1.x-dev

That's why ;)

Patches are always against the -dev release. They *might* apply against specific releases, but in our case, there are too many changes.

Hi
I tried apply patch to the latest dev release but couldn't make it anyway. Perhaps You have proper version, already patched so You could post it here?

There have been a number of changes to -dev since the patch was rolled. I may have time to re-roll the patch in the next week or so.