Hello,

Thank you first for this great module! The support has been great and I look forward to learning more about Drupal and privatemsg!

I was wondering if it would be possible to make the To: box a dropdown of Friends from User Relationships.
This way a user would not have to type in a name with possibility of misspelling, but rather just choose a friend from a dropdown to send a message to.

Thank you very much in advance!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

litwol’s picture

Version: » 6.x-1.x-dev

Lets discuss user experience. How do you propose we deal with users that have many friends. Drop down for a large list is not a very good solution.

Also drop downs dont allow you to specify multiple recipients for your message.

Berdir’s picture

multiple recipients are possible and I have a module that enables drop-down recipient lists, however, it is currently limited to roles, but very configurable. I plan to release it once the necessary changes to privatemsg.module have been commited (read-all patch and the mentioned follow-up)

Bilmar’s picture

Thank you Berdir!

This addition will be very helpful and I believe it would dramatically increase user experience!
I will follow the patch info and look forward to testing it out.

to answer litwol - i would suggest not to use the dropdown if users have many many friends on your website.
for my purposes it would be very convenient for users =)

Bilmar’s picture

Hello Berdir,

I was wondering if your new add-on will be available soon for testing.
I would appreciate any guidance in implementing this dropdown for the TO: field.

Thank you!

Berdir’s picture

Status: Active » Needs review
FileSize
6.84 KB

Ok, attached is a first version of my mentioned module...

- The admin UI is based heavily on pm_block_user
- Currently limited to ruleX -> ruleY configurations, the plan is to extend it at make it possible to "inject" all sort of user lists, but that does currently not yet work.
- Currently enables itself on write/reply form, forward form (see privatemsg_forward) and the filter author form (that is quite limited currently, as it only displays authors you are allowed to write). Not really configurable atm.

jaron’s picture

hi berdir,

i've been working through this with the some of the other sub-modules (ie forward) and have noticed a new issue that popped up. it has to do with a thread that is started by someone who has the authority (based on recipient lists) to send a message to someone, but then the other person doesn't have the authority to start a message with the original author. in my scenario, we are using the recipient list to limit only certain roles' initial messaging options. we don't want to limit threads that are begun by higher up roles. however, with the most recent iteration of the recipient_list.module, the receiver in this scenario cannot respond to the original author. there isn't any form presented. i fixed this by deleting the following code (the last lines of the module):

/**
* Implements hook_privatemsg_block_message().
*/
function privatemsg_recipient_list_privatemsg_block_message($author, $recipients) {
$rules = variable_get('privatemsg_recipient_list_rules', array());
$recipients_from_list = _privatemsg_recipient_list_load_recipients($rules, $author);

$blocked = array();
if (!empty($recipients_from_list)) {
foreach ($recipients as $recipient) {
if (!isset($recipients_from_list[$recipient->uid])) {
$blocked[] = array(
'uid' => $recipient->uid,
'message' => t('Not allowed to write a message to !name.', array('!name' => $recipient->name)),
);
}
}
}
return $blocked;
}

however, i am not a programmer and don't know if there will be unintended consequences of that deletion. please let me know what you think of that change.

i am guessing that this additional code is to make the module work more in-line with the pm_block_user module. my question then would be that to me, the two modules provide different uses. the pm_block_user module is to actually block users from messaging one-another, whereas the recipient_list is simply a way to limit the recipient list for a user who starts a thread. from my perspective, that limitation should only exist on the initiation of a thread. if i want to limit a user in a greater way, then i would implement the pm_block_user. what is the argument for the greater blocking functionality of recipient_list?

thanks.

Berdir’s picture

Category: support » feature

Setting the correct category, this is a new feature, not a support request.

osopolar’s picture

Any progress here? The best thing would be to have a view which provides the users - similar to cck user reference. I believe, this functionality could be derived from the cck user reference.

You also have different possibilities how to show the audience (see for example the similar cck node relationships module, how it work's together with cck node reference).

I did not check the details but I think that we need to provide a list of recipients user id's. If this will be done by views its up to you who will be in the audience list. And maybe its up to your template (or form alter function) how you provide an addressbook like overview (as drop down box or as pop up window).

Some more (different) inspiration: http://drupal.org/node/371034

jaron’s picture

Version: 6.x-1.x-dev » 6.x-1.0
Category: feature » support

hi berdir,

with the current release of privatemsg (1.0 - not the .dev), the recipient_list sub module causes the following error when you preview the message prior to sending it:

warning: preg_match() expects parameter 2 to be string, array given in /Applications/MAMP/htdocs/10_27ddoMirror/includes/bootstrap.inc on line 777.

when the message is sent, everything is fine. this is just on the preview. from an end user perspective, though, it's a bit disconcerting to have an technical error show up. any way around this?

thanks,
jaron.

Berdir’s picture

@jaron

I can confirm this, but the fix requires probably a change to privatemsg.module, should however be easy.

In the following code part in the function privatemsg_new():

  if (isset($form_state['values'])) {
    if (isset($form_state['values']['recipient'])) {
      $recipients_string = $form_state['values']['recipient'];

    }
    $subject   = $form_state['values']['subject'];
    $body      = $form_state['values']['body'];
  }
  if (!$thread_id && !empty($recipients_string)) {
    drupal_set_title(t('Write new message to %recipient', array('%recipient' => $recipients_string)));
  }
  elseif (!$thread_id) {
    drupal_set_title(t('Write new message'));
  }

You need to move the first if below the other part so that it looks like this:

  if (!$thread_id && !empty($recipients_string)) {
    drupal_set_title(t('Write new message to %recipient', array('%recipient' => $recipients_string)));
  }
  elseif (!$thread_id) {
    drupal_set_title(t('Write new message'));
  }
  if (isset($form_state['values'])) {
    if (isset($form_state['values']['recipient'])) {
      $recipients_string = $form_state['values']['recipient'];

    }
    $subject   = $form_state['values']['subject'];
    $body      = $form_state['values']['body'];
  }
rburgundy’s picture

subscribing. i confirmed issue at #9 and used Berdir's instructions at #10 which fixed the issue. thanks!

jaron’s picture

thanks berdir.

that did solve the problem.

rburgundy’s picture

Will this be added to 6.x-2.x-dev or compatible with 6.x-2.x-dev ?

I tried using the privatemsg_recipient_list module with 6.x-2.x-dev and it didn't work.
I was also not able to find the code to change as instructed in #10 in the 6.x-2.x-dev version of privatemsg.module

Thanks

YK85’s picture

+1 subscribing

YK85’s picture

I would also be greatful if this module can be taken out for a spin with Privatemsg 6.x-2.x-dev
Is there any plans for this in the near future? Many thanks!

Berdir’s picture

Already did that, just forgot to upload the update.

As for the attachments module, I'm attaching the patch *and* the tar.gz. You only need either the patch or the tar.gz. There is also a patch to fix the reported preview bug, that is already part of the big patch, you only need that when using the tar.gz.

Note that the module should work fine together with Privatemsg 6.x-1.x except that the patch to fix the preview bug won't apply and needs to be fixed manually (see above).

Bilmar’s picture

User Relationships module comes with a user_relationships_api.privatemsg.inc which allows the below functionality of restricting privatemsg message to only between users that have a relationship (autocomplete only shows users that have relationship as well).

Privatemsg
Restrict Private Messaging to only related users:
[ ] Allow sending messages to all users
[ ] Allow sending messages to all users, users have option to accept messages only from their confirmed relationships
[x] Allow sending messages only to confirmed relationships (You probably should enable "Suggest only relationships" below)

I noticed that this privatemsg_recipient_list module breaks this functionality and shows all users of role type x.
Would it be possible to extend the compatibility with User Relationships?
Essentially, I am aiming to have in the dropdown only users that have a relationship ('friends').

Thanks very much in advance!

Bilmar’s picture

for your reference:
user_relationships\user_relationships_api\user_relationships_api.privatemsg.inc

apmsooner’s picture

To accommodate multiple user selection in the private message to: field without having a lengthy dropdown, could we possibly utilize this module http://drupal.org/project/multiselect and furthermore allow us to pull from a view much like the user reference field does?

YK85’s picture

For multiple user selection, it would be nice to have a single select dropdown that says "Select a participant", then when a name is selected that username is added to the To: field as a box and the single select dropdown resets to "Select another participant"..then user can repeat to continue to add more users.

Multiselect module is great but it will take a large space at the top of the message that will take away from the current clean design of Privatemsg.

robby.smith’s picture

subscribing

cerup’s picture

subscribing

freddyseubert’s picture

Will this remain as a patch? Or will it be included in the next stable release of privatemsg?
Berdir: Thank you anyway for the great work :)

nilsja’s picture

subscribing...

and supporting apmsooners idea with multiselect... that would be great

jminker’s picture

subscribing too!

BenK’s picture

Component: User interface » Code

Subscribing

Ela’s picture

Version: » 6.x-2.x-dev

subscribing

BenK’s picture

Status: Needs review » Needs work

I briefly discussed this with Berdir in IRC and wanted to re-start the discussion of this here. The existing patch is quite old, so it most likely will not apply.

Here's what I'm thinking in terms of the dropdown:

1. It should be additional to the autocomplete field (instead of replacing it).

2. It should be configurable in the module settings what appears in the dropdown.

3. Ideally, each available recipient type should be displayed in the settings, including all User Relationship types, all roles, and all organic groups that the user has permission to send to.

4. Perhaps in the send message UI it would appear to the right of the autocomplete (same line). On that line, it could be displayed as follows:

To:
[autocomplete field] or send to the following recipient list [dropdown field]

Question: Berdir, would you rather do this in D7 and then backport to D6?

--Ben

BenK’s picture

One more thing: Berdir had a great idea for a potential Views integration that I wanted to document on this thread....

Basically, the idea is that you could select an arbitrary view of users (probably limited to that) and they would show up in the dropdown/select list, too. An example use case would be using the Flag module to allow users to bookmark/remember users. Then, all of those bookmarked users would show up in the dropdown list. Perhaps they could show up as either individual users or else one "Bookmarked users" entry?

--Ben

capellic’s picture

I just installed this module and I thought I'd add some screenshots so that everybody can see what it does right away.

obiwankaynobi’s picture

subbing for d7. tried hacking it myself but i ended up making a pie instead

daudetalphonse’s picture

Status: Needs work » Needs review

#16: privatemsg_recipient_list_2.patch queued for re-testing.

Status: Needs review » Needs work

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

daudetalphonse’s picture

Status: Needs work » Needs review
Berdir’s picture

Category: support » feature
Status: Needs review » Needs work
Omio’s picture

http://drupal.org/node/563424#comment-2571294
Unfortunately this patch doesn't work with 6.x-2x-dev version. Does anyone have any appropriate patch, solution? I really need the same patch for 2x version.

jenlampton’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Assigned: Unassigned » jenlampton

Since this is a request for a new feature (imo it's actually a bigfix or maybe just a UI improvement, but to each his own) I'm bumping it up to 7.x. If we get a reasonable fix there then we can backport it to the 6.x version.

I took a look at the patch at http://drupal.org/node/563424#comment-2571294 and I think it might be overkill. I'd prefer to add a setting that would allow each site to define weather it would prefer a drop-down (if people will have a reasonable number of friends and be seding messages one at a time) checkboxes (if people will have a reasonable number of friends, and be sending messages in bulk) or an auto-complete (if people will know how to spell/type all 500 of their friend's user names exactly - as on drupal.org) :)

jenlampton’s picture

Okay, here's a go at the settings page and how it changes the form element. Still need to get all the magic from the autocomplete results into the select / checkbox results, but wanted to get this code back up sooner rather than later for a review.

Also getting some weird errors in preview... so leaving as needs work.

Berdir’s picture

- The function for the options seems unnecessary if it's only used there. And should have a docblock if we want it :)

- The load shouldn't be something completely new but re-use existing API's. We should probably do something similar as privatemsg_autocomplete() without the !empty check and without some other parts. It's possible that the autocomplete callbacks need to be changed to support an empty "search"

- Also, I guess we want to add a hard limit on the results, not sure what to do when it's more but displaying a list of usernames on a site with 100k users wouldn't be that cool :) As you can see, the privatemsg_autocomplete() function and the callbacks support that alraedy.

ivnish’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)
andypost’s picture

Status: Closed (outdated) » Needs work