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.

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.

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?

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.

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.

+ * Implementation of hook_privatemsg_user_settings.
+ *

- 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)

user_save($user, array('privatemsg_disabled' => FALSE));

And then access it with

if (array_key_exists($user->data['privatemsg_disabled']) && $user->data['privatemsg_disabled'] == FALSE) {

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

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?

Thanks for the re-roll. Don't worry about the amount of points below, your code is very clean, my points are mostly about design decisions/UX. If you have any questions, please post them here and I'll try to answer asap.

+++ privatemsg.install	(working copy)
@@ -103,9 +103,22 @@ function privatemsg_schema() {
-  return $schema;
+   return $schema;

This seems to have too many spaces...

+++ privatemsg.pages.inc	(working copy)
@@ -450,6 +450,65 @@ function privatemsg_delete_submit($form,
+function privatemsg_user_settings($form_state, $uid = NULL) {

We decided to go away from a settings page below /messages/ and instead use the user edit page (Not the users.data storage, we just visually embed it).

This makes a lot of custom code, permissions, menu entries and so on unecessary and is imho better UX because all settings a user can edit are at the same place.

You can find an example inside pm_email_notify_user(), hooks form and submit. You could also think about providing a Privatemsg category so that we can put the email setting there too in a follow-up patch.

+++ privatemsg.pages.inc	(working copy)
@@ -450,6 +450,65 @@ function privatemsg_delete_submit($form,
+  $form['disable'] = array(
+    '#type' => 'radios',
+    '#title' => t('Private Message Receiving'),
+    '#default_value' => (int) !privatemsg_is_disabled($user),
+    '#options' => array(t('Disabled'), t('Enabled')),

Maybe using a checkbox would make more sense here? Not sure, but that's we've done in other places. Also, a description would be great.

+++ privatemsg.module	(working copy)
@@ -27,6 +27,7 @@ function privatemsg_perm() {
     'administer privatemsg settings',
+    'administer privatemsg user settings',

If we place it in the user edit page, that should be handled by the administer users permission...

+++ privatemsg.module	(working copy)
@@ -257,6 +286,25 @@ function privatemsg_view_access() {
+    $account->privatemsg_disabled = (db_result(db_query('SELECT COUNT(0) FROM {pm_disable} WHERE uid = %d ', $account->uid)) <> 0);
+  }

you don't need the COUNT(0) here, "SELECT 1 FROM" .. is faster and enough.

+++ privatemsg.module	(working copy)
@@ -840,6 +888,11 @@ function privatemsg_sql_unread_count(&$f
+  // exclude users that have disable private messaging
+  $fragments['inner_join'][] = "LEFT JOIN {pm_disable} pd on pd.uid=u.uid";
+  $fragments['where'][] = "pd.uid is NULL";

Probably a faster option would be to use a "NOT IN (SELECT pd.uid FROM {pm_disable} pd)" since that sub-query needs to executed only once.

This review is powered by Dreditor.

Your changes look visually good, thanks for the fast reroll!

Î'll test this as soon as I find the time.

One last thing you could do if you have the time and are interested in doing so. It would be great to have a test for this. Nothing complicated, just trying to send/recieve a message from/to a user that does have disabled private messages.

You can start with an already existing test case (a method that begins with "test...") in privatemsg.module and either extend that or create a new one.

I would do something like that:

- Create two users (let's call them A and B), both with read/write permission
- Login as user A
- Write a message from A to B
- Login as user B
- Disable privatemsg for user B (through the UI)
- Check that the previously sent message is still available
- Check that B can't response to the message nor send a new one
- Login as user A
- Try to send a message to user B and check that the correct error message is displayed.

With that, we should have covered the whole patch (I think) and can be quite certain that it won't get broken through other patches).

Again, you don't need to do it but it will greatly increase the chances that your patch is commited since I'd have to do it on my own if you don't. If you need assistance in writing tests and/or getting simpletest running, you're welcome to ask here or in IRC (#drupal-games)

Awesome work, thanks very much!

+++ privatemsg.test	(working copy)
@@ -333,6 +333,68 @@ class PrivatemsgTestCase extends DrupalW
+    $account = user_load($disableduser->uid, TRUE);

Not sure, is that line really necessary? You only need the uid before the second user_load()

+++ privatemsg.test	(working copy)
@@ -333,6 +333,68 @@ class PrivatemsgTestCase extends DrupalW
+    $this->assertFalse($result['success'], $message = 'Message reply was not sent.');

The "$message = " is unecessary here, I think.

I'm on crack. Are you, too?

Ok, I finally tried to patch and everything looks fine - commited against 6.x-2.x! Thanks again!

This needs to be ported to 7.x, I assume the tests have to be updated a bit and it also needs to use DBTNG. You are welcome to port the patch but I will do it sooner or later myself.

Ported and commited to D7.

Noticed this when porting to drupal 7 but forgot it then. Aka, it's fixed in Drupal 7 already:

  if ($category == 'account' && isset($edit['pm_enable'])) {

I will roll a patch, but it might take a few days so if you can spare a few minutes and do it, that would be great.

Added the check...

Actually, I've seen that I've already handled that here: #691030: My account page visibility. Setting back to fixed.