Privatemsg To: Realname support

I do have a module that allows this but I need to clean it up before I can upload it. #369334: Realname for Privatemsg autocomplete is the wrong approach.

Ok, attaching a module I wrote for someone who agreed to release as part of Privatemsg.

- Requires the latest version of realname ( that comes with the realname table)
- To have a working autocomplete, you need to comment out the following line in realname.module inside the function realname_form_alter() (at the end):
$form['privatemsg']['recipient']['#autocomplete_path'] = 'realname/privatemsg/autocomplete';

What this module does:
- No configuration required (anymore) thanks to the realname table and Support for complex realnames
- Full autocomplete support including name resolve of realnames
- Displays realnames in title and to field when using a URL like /messages/new/1,2,3
- Re-adds support for realnames on the thread view pages

+1 subscribing, I tested the module at #3 and it works great. Thanks for the awesome work.

#4 "I also realized that jdoe also shows up in the autocomplete, but I believe this is as per design?"
I also confirmed that both the regular username and the realname shows up in the autocomplete.
Should it not be just the realname when this module is enabled?

Will we see this added to the most recent dev in the near future? Many thanks!

Thanks for testing...

- I will add an option to hide/show user names in the autocomplete. I'm sure there are cases where you might want to write a message to an username so I don't want to loose that option completely.

- I want to write some tests first before commiting this

- See also #369334-36: Realname for Privatemsg autocomplete, I first need to get in touch with the maintainer of realname to figure out how to continue. I will not commit this until we have figured this out because it currently requires you to hack realname.module and while it would be possible to work around that, It is more than ugly to work around a workaround ;)

An option to hide/show user names in the autocomplete sounds great!
Yea, I agree there is probably a use case for having both available.

Thanks for the great work!

Looking at #369334: Realname for Privatemsg autocomplete, I'm guessing no progress/decision from Realname module side? =/
Really appreciate your hard work. Thanks!

Hi Berdir-

I was wondering if NancyDru has chatted with you regarding #369334: Realname for Privatemsg autocomplete outside of the thread? (she looks to be pretty active on drupal.org looking at her track)

It would be awesome to see this area of privatemsg-realname further develop!
I really appreciate your work and support.

Nope, I haven't heard anything.

The module needs a re-roll, the autocomplete doesn't work anymore. (where conditions changed in privatemsg.module)

FYI, I installed and configured the realname and privatemsg_realname modules at the newly installed demo site: http://demo.worldempire.ch, if someone wants to test it.

Fixed the autocomplete.

- An option to select between only realname/username or both is planned and will be added before this is commited (here or to realname.module)

- Yes, it does already not duplicate users in the autocomplete, but it is pretty random if the used one is the name or the realname if they are similiar (it does not matter if they are the same :) ), so we need another check to favor the real name if there are multiple matches...

Thanks for testing :)

Hi,

When I use privateMsg in combination with User Relationships and Realname the autocomplete field that normally would suggest only relationships does no longer work. My guess is that it has something to do with altering the autocomplete field twice. I've tried this patch to solve my problem but this doesn't do anything as far as I can tell.

Any suggestions on fixing this problem?

The current implementation in realname.module does not alter the query but completely overrides the whole function which does the autocomplete. Obviously, the alter hooks of UR doesn't work anymore then.

You need to comment out a line in realname.module as described in #3.

It works!!!

Thanks Berdir for your quick reply and this incredible module! :)

subscribing.

I'm sure it's just me but the only way I could get the patch for privatemsg_realname posted in #14 to work was if I modified line 27 from

$fragments['where'][1] = "(r.realname LIKE '%s' OR u.name LIKE '%s')";

to

$fragments['where'][0] = "(r.realname LIKE '%s' OR u.name LIKE '%s')";

I'm using the most recent dev version of realname (6.x-1.x-dev) and the production version of privatemsg (6.x-1.2).

Hi Berdir!

I saw your comment in #369334: Realname for Privatemsg autocomplete

When you have time, I was wondering if you could share what is needed (patches, hacks) for PM 6.x-2.x-dev + Realname integration at this moment, and possibly what will be needed in the future?

Thanks!

Subscribing...

subscribing

Howdy,

I'm having a problem when two users have the same realname, the message is going to a different user (possibly the user with the same realname but lower uid number).

uid:5 / realname: John
uid:7 / realname: John

When a user sends a message to www.example.com/messages/new/7 the To: shows 'John', then once the message is sent the message goes to uid 5 instead of uid 7 =O

Anyone else experiencing this issue?

Super cool module and I hope Realname integration will work sometime soon.

Well, that's currently pretty much by design. An earlier version of the module even had some code to avoid saving duplicates in the first place, but real names aren't unique.

It's possible to solve that, but I'm not sure how. Surey, we could do something like "John [uid:7], someoneElse" but I'm not sure if users will actually know which one they want when they type in "John" and can then select between "John [uid:5]" and "John [uid:7]"

Hi!

I'm using the Views integration to show a list of users and a Send a message link, so it is like:

John | Rogers | Send a message << when clicked the url is www.example.com/messages/new/5
John | Murphy | Send a message << when clicked the url is www.example.com/messages/new/7 but message goes to the other John

I think the below urls should show "John" in the To: but the bug seems to be that if the url is /7 the message is still being sent to /5 because the realname's are the same. So in the case that URLs are used (views send message link), the url is being ignored and the realname is only being used to determine who the message is going to?

www.example.com/messages/new/5
www.example.com/messages/new/7

Maybe a cool option in the settings for Realname integration would be:

[ ] Use Realname
>>>[ ] Include uid in To:
>>>[ ] Include account email in To:

Then it would show:
John [uid:7]
John [jm@example.com]

I agree and see what you mean with the issue of typing a realname into the To: [ ] at www.example.com/messages/new because I'm sure there are many John's and many other people with the same first names out there (if firstname is used as the realname). But for my site where I don't allow users to go to www.example.com/messages/new and only send messages from the Views link, only showing the Realname with the "include uid" or "include account email" works great. Maybe the first step can be to differentiate when www.example.com/messages/new and www.example.com/messages/new/5 (with uid) is used?

I really hope you can find the time to improve this area of Privatemsg-Realname Integration.

Best

Hm.

I don't like adding mail addresses to that, because you usually don't want to show them, that's a private field. If they know your mail address, they can probably write you directly instead of using the site at all :)

UID is the most specific but it doesn't help the user much. Simply using the username might actually help the user but there might be uses cases where you don't want to make the username visible for others either.

So.. what about an obtion to select between UID and username?

There would be a check to see if realname is unique and if not, it would be displayed as "Real Name [uid or username]".

Will get back to this once #884504: Remove privatemsg fieldset, clean up the form and fix a PHP 5.3 issue is commited as that will break the broken integration that realname.module currently provides :)

Hey Berdir,

I like the UID and username option. One idea: How about a third option for user picture (avatar)? That's the way I usually see the issue handled on sites like Facebook (with a default picture used for those who didn't upload one). Usually a picture is the easiest way to clear up the confusion.

For those sites in which only some users have pictures, other options could be "user picture if available, UID otherwise," or "user picture if available, username otherwise". Or perhaps the user picture is a separate configuration option that, if enabled, could be displayed in addition to UID or username if it is available for that user.

Then in the D7 version of this, the user picture could actually use the default imagecache preset (usually thumbnail).

Thoughts?

--Ben

A site I'm building is fully integrated with Realname except for Privatemsg =(
Any chance there will be further patches to extensively test in the near future?

Great module and plz keep up the superb work!

Well If you use realname on a Content profile you can use the http://drupal.org/project/unique_field module to define the field you are using with realname as unique. No more duplicates then.

Yeah, no more duplicates. The initial version of this module also contained code that checked this for profile.module.

However, reality is that real names are not unique. What if you're name is "John" and there is already a "John". Use "John2"?

The real fix for this is here: #850022: Further improve autocomplete for different recipient types and name conflicts between them. With the patch from there, privatemsg.module will automatically ask the module that provides the suggestions for a unique version if there are multiple "John"'s and will also not accept non-unique recipient names anymore.

Once that issue is commited, I can change privatemsg_realname.module to support that feature.

subscribing

I'd like to get working on Realname integration now that http://drupal.org/node/850022 has been committed. Berdir, do you want to update the latest patch to take advantage of the new name conflict feature? Then, I can test and report back.

What I'd really like to do is get Realname integration working in the D7 version of Private Message (since Realname module just released an official D7 branch). But I figure that since the D6 version is already underway we can get that one working and then port to D7. Or would you rather work the other way around?

--Ben

Ok, here is an update.

- Being able to change the format callback allows to make this logic simpler and better at the same time
- Replaces all remaining direct usages of $account->name with privatemsg_recipient_format()
- When using messages/new/UID, the unique name is now used. Not sure about this...
- An option allows to configure if UID, name or mail should be used as unique identifier.
- An option that allows to choose if username should be searched too.

sub+3

Subscribing. Was surprised when I uploaded a dev recently that didn't have realname support. This is one of the last missing pieces before I can let my site go live.

#36: privatemsg_realname3.patch queued for re-testing.

Can't reproduce the API test fails, fixed the filter ones.

seems like we are near to fix this problem

only 3 errors are remaining now,

love to watch the progress..

What about trying out the patch and help by testing instead of just watching progress?

I can see how many fails are remaining for myself.. ;)

sorry berdir, if i hurt you...

Trying to figure out why the tests fail...

@imDhaval: You didn't hurt me ;) Just remember that every time you post in an issue like this (with many comments), dozens of people receive mail notifications.
Additionally, it isn't enough when the patch passes the tests because there are no tests for the new features right now, so manual testing be a few people is really important, especially given all the configuration options and things that realname does and provides.

Hey Berdir,

I just completed the first round of manual testing on the latest patch (#47).

First, here's what's working:

* At the /messages list, the username is being properly replaced with the realname.
* When viewing a message, all instances of the username are being properly replaced by the realname. This includes both at the thread and message levels.

And here's what I can't get working:

A. I don't see any new options on the PM settings page. Specifically, I don't see an option allows to configure if UID, name or mail should be used as unique identifier. I also don't see an option that allows to choose if username should be searched too. Am I looking in the wrong place? I also tried clearing the cache. I expected to see them either in the "Display settings" or "Integration settings" fieldsets.

B. Realnames aren't showing up in the autocomplete when sending a new message. You can't send a message to a manually entered realname either.

C. Even though realnames are used when viewing a message, if you click the 'block' link to block a user, the username (instead of the realname) is being shown on the blocking confirmation form.

--Ben

@BenK: Are you sure that privatemsg_realname.module is enabled? :)

EDIT: No you don't, since it's missing from the patch ;) Working on an update

Ok, this time with the privatemsg_realname.module...

Ignore test_bot.patch, that's just for the testbot.

Hey Berdir,

Okay, tested the new patch and now I'm finally seeing the settings and things are working better! :-) It's already working quite well, but here's what I noticed:

1. The "Search usernames for autocomplete suggestions" isn't working properly for me. Regardless of whether or not this setting is checked, I'm getting usernames in the autocomplete. In fact, the only difference I can detect is when the setting isn't checked, the "admin" user appears in the autocomplete. If the setting is checked, the admin user doesn't appear. One possibility: If the user doesn't have a realname specified (those fields are empty), is it supposed to show the username instead? I wouldn't expect that, but I suppose it could be a feature (but maybe an explicit setting would be needed).

2. When a user is blocked using the 'Block' link on a message, the user's Realname is properly used on the confirmation form. But once the blocking form is confirmed, the message printed to the screen uses the username instead of the Realname. For instance, if a user's username is "person1" and his realname is "Bob Jones," then the message reads: "person1 has been blocked from sending you any further messages." Instead, "Bob Jones" should be used.

3. I think the label system that we use to identify users, roles, etc. is a little confusing when used with realname unique identifiers. For instance, in the case of Bob Jones, the appearance in the autocomplete (if e-mail is selected as the unique identifier) will be: Bob Jones [user:bob@jones.com]. So it looks like "bob@jones.com" is the username even though it's an e-mail.

Any ideas for changing the format of this to make it clear that the "user" label isn't referring to the unique identifier? Perhaps one of the following:

a. Bob Jones [user] (bob@jones.com)
b. Bob Jones [user] (e-mail: bob@jones.com)
c. Bob Jones [user] [bob@jones.com]
d. Bob Jones (bob@jones.com) [user]
e. Bob Jones - bob@jones.com [user]
f. Bob Jones | bob@jones.com [user]

Thoughts? Preferences?

4. What about doing some token integration here? Add an additional option that lets the site admin specify his own token string as the unique identifier. For instance, in my own use case, I might want to use city and state as the unique identifier like this: "Bob Jones - Los Angeles, California [user]". So if we provided a text field with token integration, the site admin could specify token values for any fields that were available from the token module. Plus, they could add their own labels (non-token text) into the string.

But if this is complicated to implement in D6, I'm OK with leaving out this feature for now and trying to implement it in the D7 version (when fields and tokens will be in core and when we have the cool token browser available from contrib).

--Ben

(I have written a lengthy response with lots of explantations but d.o. has eaten that, so this will be short, we can discuss in IRC if it is not clear).

1. This is working as designed. If a user doesn't have entered a realname, the username is used as the realname. Have a look at the realname table. It lists the username for all those that don't have a real realname. And we must show all users at least once if they have a realname or not.

2. Will fix that.

3. I don't get your point. Why is "So it looks like "bob@jones.com" is the username even though it's an e-mail." a problem?

And I don't get this sentence at all: "Any ideas for changing the format of this to make it clear that the "user" label isn't referring to the unique identifier?"

And I need something that is easy to parse, this has to work both ways. Sure, we can change it to realname [user] [identifier] for example but how is that better than realname [user:identifier]?

4. See above. Once they are complex enough (multiple tokens, spaces, ..) It is not possible to parse such a string into a user object again. This was a problem with realnames too before the module added the realname table. So we would have to maintain our own table and that is quite a bit of work. Also, this has nothing to do with D6 vs. D7 since it is not a technical problem, it is a logical one.

So, short answer: No.

Berdir,

Based on our conversation on IRC, here are my updated notes:

1. Thanks for the explanation. However, I still think this isn't quite working. As I now understand it, if a user doesn't have a realname then the username is used instead. So that's working fine. But checking the "Search usernames for autocomplete suggestions" box doesn't actually cause usernames to be searched.

Here's how I'd expect it to work: I have a user with username "editor". His realname is "Fred Editor". So if I type an "e" in the autocomplete box (with that setting checked), I'd expect to see "Fred Editor" in the autocomplete (since usernames are being searched and "editor" is a match). But currently, "Fred Editor" is not displayed.

In the case of the admin user (user #1), there seems to be additional errors. I have an admin user (user #1) with username "admin" and realname "Hank Admin". If the "Search usernames for autocomplete suggestions" is checked and I type an "a" in the autocomplete, I don't see "Hank Admin". Furthermore, if I type an "h" or "H", I don't see "Hank Admin" either. It appears that if that setting is checked, user #1 never shows in the autocomplete (even though I can send to user #1 by typing it in manually). Only by unchecking the setting does "Hank Admin" ever show up (if I type an "h").

1b. (NEW) Found what appears to be a fairly major bug. In fact, it might actually be two separate bugs (one that is related to this patch and one that may or may not be). Basically, if you have a user without a specified realname (say, username is "person2"), then everything appears fine in the autocomplete: If you type a "p" then "person2" displays. But if you actually try to send to that person, then the dialog box pops up that asks you:

The site has multiple recipients named person2. Please choose your intended recipient:
person2 [user:person2]
person2 [user:person2] 

The problem is that there is only one person2 on the site and this dialog box is not needed. It appears to think that there is a conflict with a duplicate of itself. This bug occurs regardless of whether "Search usernames for autocomplete suggestions" is checked or not.

Now here's the second bug: If you click either of the two recipients presented and send the message, then a white screen of death (WSOD) appears and the message is not sent. (I don't see any error messages in my PHP error logs, however.) This may possibly be a separate bug because I am getting the same white screen of death if I have a user named "editor" and a role named "editor": If I click the user, I get a WSOD. If I click the role, the message is successfully sent.

Thoughts?

2. Still needs to be fixed as you indicated.

3. After discussing this in IRC and thinking some more, let's keep this in the existing format, but with a minor tweak. Currently, the format is:

"realname [user:identifier]"

Let's just add a space between "[user:" and "identifier]" (a space after the colon) so that it reads like this:

"realname [user: identifier]"

This will help a little with readability for the end user, I think.

4. We discussed a totally different solution for this in IRC. Here's what Berdir came up with for a solution:

berdir: Ok, what about this: We already have a replaceable format recipient callback function, that you can override. privatemsg_realname.module does that. See the function "privatemsg_realname_privatemsg_recipient_type_info_alter" in privatemsg_realname.module. That is where it tells privatemsg.module that it should use a different callback to display users. That callback is actually a theme function. So, all we do in privatemsg.module to solve your problem is pass the new option "autocomplete" => TRUE to it. Then, you can either write your own module (with a higher weight than privatemsg_realname so that it is executed afterwards) and override it again to use your own theme function. Or you simply override the theme function in your theme. Then, you can display whatever additional information you want (just needs a few lines of custom code).

Oh, one more change is necessary, actually. Autocomplete allows to return an identifying string, that will end up in the textfield and a visual string that is displayed in the selection. Currently, those are identical in privatemsg (except the identifying string has the existing, entered names as prefix). We need a way to make them different. This way, you could even hide the technical identifier in the displayed string, if you want to. So it would show "Bob Jones (Los Angeles)" in the autocomplete and insert "Bob Jones [user:123]" into the textfield. Maybe we can implement something similiar to the fancy autocomplete that facebook has (the colored thing with the x) and totally hide the technical identifier (but that is something for later).

--Ben

1. Is working fine for me, not sure.

2. Fixed.

3. Changed. Updated the default, the looking works both with and without the space.

4. Ok. I really think we should do that in a separate issue, as a follow up. Technically, this doesn't have to do with realname integration at all, it can be just as useful for the default user display, role display and might for example also allow user profile images in the autocomplete.

Attaching an updated patch. Note that this contains debugging stuff to help figuring out what's up with the testbot. Do not use this for manual testing.

Test patch only...

Fixed 1b)

Still test patch, however.. but I think I found the source of the problem.

This patch should fix 1a).

Still a test patch, don't try this.

Next try.

D'oh! The patch actually was missing the file that I did changes in the last 3 uploads.

This will hopefully do the trick.

Ok, still no luck, init_theme() was the wrong function. Maybe this one works.

Getting there...

Ok, there is no way to make this work the clean way.

Added a special case to privatemsg_recipient_format(). This should pass the tests, debug stuff is removed too.

Ok, fixed the last two fails, this was actually a bug. This should be ready for testing now.

Hey Berdir,

I tested the patch in #73 and a lot has been fixed. There are still a few bugs that I have outlined in my report below:

1a. This has been fixed!

1b. Part of this has been fixed. I'm no longer getting a duplicate entry for person2 (that asks me to pick which person2 I want to send to). But now, sending to any user that has the same realname as another user results in a White Screen of Death. To test, I have two users: person1 and person2. Both have the realname "Bob Jones". But when I choose either "Bob Jones [user: person1]" or "Bob Jones [user: person2]" from the autocomplete and send to him, I get a WSOD. It could be a problem with the parsing of the "[user: person1]" part.

2. The blocked message is now correct, but we've got a problem with the "unblock" confirmation message. If you unblock a user with a realname, you get the same confirmation message as if you were blocking him. Specifically, the unblock confirmation message incorrectly reads: "Bob Jones has been blocked from sending you any further messages." It looks like we may be missing a realname string for unblocking a message.

3. This looks good. I like the added space!

4. Agree to postpone this and create a separate issue. I'll do this soon.

5. (NEW). I noticed one more thing... not sure if this is a bug or if it works as intended. It's not necessarily bad, but I thought I'd mention it. Basically, if the "Search usernames" option is checked and you have two users named "person1" and "editor" (both with realnames "Bob Jones"), there is a discrepancy in the autocomplete. If you type in "b" you'll see both "Bob Jones [user: person1]" and "Bob Jones [user: editor]" in the autocomplete. So far, so good. But if you type an "e" in the autocomplete, you'll just see "Bob Jones" in the autocomplete (not "Bob Jones [user: editor]"). As a result, upon sending you'll get a dialog box asking you to choose which "Bob Jones" to send to. So if a user types an "e" in this case, should the autocomplete say "Bob Jones [user: editor]" rather than just "Bob Jones" (because there is another Bob Jones in the system, albeit one that didn't match the autocomplete)? I'm not even sure this is technically possible, but I thought I'd flag the issue.

--Ben

Ooops... I didn't see that you had posted a new patch in #75 before I began testing. I tested the one in #73. Did any of the bugs I outlined in my notes get fixed in #75? Do I need to re-test or do you want to address the bugs I mentioned first?

--Ben

2. That's why the tests failed, this is fixed. The other stuff is not.

Hey Berdir,

I just tested the patch in #75 and confirmed that 2. is now fixed. I also confirmed that the other issues I mentioned in my prior comment remain.

So it looks like the only items we have left are 1b. and possibly 5. Most likely, one more round of testing and then we should be able to commit and begin work on the D7 port.

--Ben

Really fixed 1b now.

5 can't be solved right now. There are more edge cases, for example having a role editor and a user editor with realname Fred Editor, searching for editor shows "editor" and "Fred editor", selecting editor then gives you the duplicate widget. Not perfect, but I think what we currently have is already quite good.

Actually, we are way better than facebook, which doesn't give you any indication to what person you are writing a message when you have two friends with the same name ;)

Tested the patch in #80 and everything is working great. I tested it with multiple recipients and with recipients with the same real name (in various positions in the recipients list). Everything worked perfectly so this is now RTBC! Onward to the Drupal 7 port...

--Ben

Commited, will port to D7 when I have time..

Attaching a first patch. Seems to work quite well, although I had some issues realname.module itself (It's really really nice and simple in D7 however.. )

If you receive an fatal error when saving the realname pattern, replace the following line in realname.admin.inc

'#element_validate' => array('token_element_validate'),

with

'#element_validate' => array('token_element_validate_token_context'),

Tried the patch in #83 and this is already working pretty well. Here are the bugs I noticed;

A. If either "Username" or "E-mail" is selected as the unique identifier and you type in a realname that has more than one possible recipient, there is an error upon selecting the intended recipient and clicking send. This is the error that displays:

Unable to send e-mail. Contact the site administrator if the problem persists.
A message has been sent to Anonymous (not verified)

Obviously, "Anonymous" should not be a recipient.

To recreate, create two users ("person1" and "person2") and give both realnames "Bob Jones". If you try to send to "Bob Jones", you will be prompted to choose which Bob Jones you mean. Upon clicking one and sending, you'll get the above error. Note that the error is gone (and everything seems to work fine) if you choose UID as the unique identifier.

Also, if you choose to send a message to "Bob Jones [user: person1]" from the autocomplete, you get the same error.

B. Regardless of whether "Search usernames for autocomplete suggestions" is checked or not, only the username is being used for the autocomplete. To test, create a user ("editor") and give him realname "Fred Editor". If you type an "e" in the autocomplete you will see "Fred Editor". But if you type a "F", no results are shown. This seems to be the case regardless of whether "Search usernames for autocomplete suggestions" is enabled or not.

NOTE: To test the above bugs, it required that I create two text fields on the user account at admin/config/people/accounts/fields. I created a "field_first" and "field_last" (for first name and last name) and then assigned those fields to be used in my realname settings ("field_first field_last"). But because tokens for fields is still a work in progress, I had to use the following patch to token module to make this work: http://drupal.org/node/691078#comment-3750106

--Ben

Yeah, I noticed after uploading the patch that the part that is responsible for the realname lookup query was still commented out but forgot to write that down here, sorry :)

OK, no worries... I'll look forward to testing the next patch. By the way, I didn't receive a fatal error when saving the realname pattern, so maybe that has been fixed in recent Realname commits.

--Ben

Ok, both A and B should be fixed.

I've tested the latest patch and can confirm that both A and B are now fixed. This is working really great. This is RTBC! :-)

--Ben

Ok, commited!

That's great this is committed, but why does the automated test say now that the patch is unable to be applied? I don't remember seeing the test fail before...

Because it was already commited :)

Has this really been committed to the 6.2x branch yet? I've installed it, reinstalled it, flushed caches, flushed browser caches, rebuilt realnames, switched between realname (profile) and realname (content profile), and still am only getting usernames to show up.

Did you enable the privatemsg_realname module?

Did you enable the Private Message Realname module? ;-)

Well, that was mighty stupid on my part. Thanks for pointing that out.