How to display a user's username (not real name) in Views once RealName is enabled?

I have a similar issue. I'm also using the Token module - and in some places [user:name-raw] created by the Realname module 'is' available - and in some instances not.

subscribing

You may refer drupal guide for api

This seems a bug, appearing in the D6 branch too
There is an option in the Realname General config tab " Overwrite user fields in view to show realnames", but it has no effect.
There is no way to get the original login name in a views field.

Major bump. This is really problematic as there's no way to get the username in views now and all views depending on the username become broken. There's a field for realname, so why hijack the username field?

A not so clean workaround:

1. Use Views PHP module.
2. In the view you want, add user UID field and exclude it from display then add global:PHP somewhere following it.
3. In the global:PHP field, you will have access to previous field values, in this case, you want the user ID.
4. In rewrite output for the global:PHP field, you can get the actual username with this code snippet.

$buser = user_load(array('uid' => $row->uid));
print $buser->name;

For Drupal 6 branch I solved the problem by clearing the views cache (admin/build/views/tools) and rebuilding RealNames for all users (admin/user/realname/recalc)

in response to #11 re: Drupal 6

Following those steps (I also have Disable views data caching checked), the result for me on Drupal 6 with realname-6.x-1.x-dev is that in my view, my Realname: Name field now displays the Username and so does the User: Name field.

That is, until I click into a user profile. After I do that once, and go back to the view, that user has the RealName rebuilt and it shows in both fields on the view.

So it seems that both fields will display the same always.

Agreed that this issue deserves some attention, especially while the RealName autocomplete issue is unresolved. (See #1194086: Real Name not working for user references). For instance, I'm using Organic Groups in Drupal 7. To add a user to a group, OG uses an autocomplete field. But the lookup only works with username, not with realname. So I tried to make a View that will show both the RealName and the username, so that group managers can search on RealName and get the username to input into the OG field. Being able to choose which way the username field displays in this context would be really helpful!

I also had trouble implementing the workaround code in #8 (I'm sure it's not you, @ominds, it's me!) but got it to work with the following modifications:

Value code:

$buser = user_load(array('uid' => $row->uid));
$uname = $buser->name;
return $uname;

Output code:
<?php print $value; ?>

Thanks for the hack, @ominds!

Is anyone working on this module? It's a great module, but I am thinking about temporarily uninstalling until this issue is fixed. I don't know if uninstalling would break anything though. Has anyone uninstalled it safely without any issues?

Realname gives us the 'Realname' field in views to output that for a user. So the module should somehow be told to not touch the views field for 'User: Name' or at least respect the field setting (under 'more') for:
"Use formatted username - If checked, the username will be formatted by the system. If unchecked, it will be displayed raw."

Or does this mean that it's actually a Views issue?

So no word on this I take it? Is nobody maintaining this anymore? This is a serious bug.

Bumping this back up as it's still a serious issue.

I seem to be able to get the username without a user_load, by creating a custom template file for the username field, and replacing
print $output;

with

print $row->users_name;

It's not a fix, but it's a bit less of a performance hit, if it works for everyone.

Here is a patch that adds a "User: Name (raw)" field to Views that shows an unaltered version of the username. There already appear to be sort, filter and argument handlers for the raw name, so this only adds a field.

Thank you very much, Zengenuity! Patch works great!

Patch works GREAT! I'm changing this to critical in hopes of getting the maintainer's attention so we can continue to beg for your help. Can you please commit this patch to the latest version? Sorry for begging but this post is almost a year old and we really need your help. Thanks and thanks again for the patch in #24

It may be a year old, but it's only been less than a week since this issue has had a valid patch that I can review. So no, please don't abuse the priority field just to get attention unless it's actually been a year since the patch has been uploaded.

Abuse? I'd say every person on here has experienced abuse. Glad we got your attention. I hope you will commit, thanks.

I've tested it and it works great....thanks

How do I speak for those of us, including your own admitted frustration, who wait, and wait, and wait? After almost a year the only thing which motivated the maintainer to show up was (or it appears) by me changing the status to "critical". I realize this can be subjective to who thinks something is critical. If you do not personally feel abused with the process of this post then I apologize for speaking for you.

I realize Dave Reid is busy and he's a great asset to Drupal and I also expect he has a great reason for not being able to tend to this, but I think there is a great argument for users who beg and never get help...until a status is changed. I'm not sure what the solution is, but there certainly seems to be a gap.

I'll help any other way I can but I applied the patch and it works great. Let me know if I can do anything else...thanks.

No, he was forced to respond because your comment was disruptive to the queue not productive. The time he(and now I) took to address that disruption is time he didn't get to spend addressing other issues and only delays actually getting this committed.

The fact is, as an open source developer you commonly have to rely on the community to resolve feature requests for you. Those with more interest will get patches and then you can review them. His absence in the issue to this point is not a big deal and a week is not a long time to wait for a review. Since Dave has a long track record of maintaining modules, attacking him on this fact only make you look bad unfortunately.

So some patience and considerate queue participation will go a long way to making the software better and making our great community... great. Until he can review and commit it, feel free to enjoy the patch that seems to be working for you.

I did a quick test, and the patch does seem to work, however it is not RTBC. Someone with more time on their hands needs to re-roll after eliminating the whitespace errors, please. I am switching status to Needs Work since the patch has now been tested 3 times, and seems to work in all 3 cases, but the patch still contains whitespace errors.

1239478-raw-username-views-field.patch:15: trailing whitespace.
    'title' => t('Name (raw)'),
1239478-raw-username-views-field.patch:16: trailing whitespace.
    'help' => t("The user's unaltered username."),
1239478-raw-username-views-field.patch:22: trailing whitespace.
  );
warning: 3 lines add whitespace errors.

I just applied and used patch - works great.

3 up 3 down, Patch in #33 looks good.

Any idea when this will be committed to Dev?

The patch works, but I'm not sure it's the right answer. Do we really want 3 username fields?

• Realname: Real name
• User: Name
• User: Name (raw)

Seems to me it should just be:

• User: Name
• User: Real name

I'll see about rolling an updated patch.

Turns out there's a lot of views user name field handlers that would probably have to be extended to fix this, so it was easier to leave the original 'User: Name' along with the current behavior and add a 'User: Username' field which is basically the field from #33 but without a separate "Realname" section.

Patch attached.

now with more unix

I'm pretty sure we already had the first two you mentioned in #40. The Raw one was the only one missing.

nope, with the patch as-is against the current dev there were the three options i bulleted in #40. i don't think a single realname field warrants it's own field category and the 'User: Name (raw)' option as named in the previous patch creates a 'User: Name (raw) (name(raw))' field line item when added to views which is an ugly/confusing name.

It's minor, but the indentation of the last closing bracket is 3 spaces and should be 2 spaces only. :-)

Can this be patch be port into drupal 6?

Any chance we can get an updated version rolled out sometime soon? There's been no change to the Drupal 7 version since May 2012. Thanks!

This is a patch for the 6.x-1.x version that is based on WorldFallz' patch in #1239478-43: How to display a user's username (not real name) in Views once RealName is enabled?. The syntax in realname.views.inc is quite different in 6.x and I'm not a Views developer, so I'm not sure the approach is entirely sound, but it Works For Me(tm).

Hello,

just to mention that the patch in #43 worked for me too.
It is very useful if you need to export user accounts through a view.

thanks

#50: realname-d6-views-username-field-1239478-50.patch queued for re-testing.

@achton thanks for the patch in #50. will test it asap and report my findings.

Restting status.

Got a workround (only for drupal 7) solving problem with field UI and Rules.

Step 1: Create a text field in user account. Name it somethig like "User Username".
Step 2: Create a rule to trigger "Before saving a user account". Name it somethig like "Check for username and create duplicate".
Step 3: Set condition "User has role(s)". And select authenticated user or desired roles.
Step 4: Add an action to "Set Data Value". In the "Specifies the data to be modified using a data selector" select [account:field-user-username] and replace it with [account:name].

Its done at its primary level and whenever user account is going to be saved this rule will run and will keep updated the username value.
You can make your way smooth by:-
1. Creating a view with VBO to update existing users.
2. And then apply a condition to check if data value for username has been modified.
3. Hide "User Username" field from user edit form so it could not me edited with "css" or "display suit" or "field permission" or _ _ _ _.

This causes RealName to actually break sites when installed. How this isn't atleast major in priority is beyond me. We have several administrative user views that use username for creating URLs . And they all broke when installing RealName.

Oh, and btw, this issue seems to be a duplicate of #1130350: Make both themed and unthemed username available to views? from April 18, 2011.

How to look at it is actually up to the maintainer of the individual project. But the common procedure for bugs like this is to first fix them in the newest stable core version (D7) and then backport to older maintained version (D6) in the same issue. So to answer your question, most project leaders on d.o seem to use a single issue for several major core-versions as long as the bug is the same.

I would probably prefer an approach that creates a replacement handler for the existing User: Name field or something that renames it to 'Login name' and adds an optional option to output the real name, and have a separate 'User: Real name' field handler. I wonder if we could get input from the Views maintainers on how to handle login name vs real name considering that the existing Views handler tries to do both?

It's also unclear if the RTBC here is for the latest patch or the one before it. There doesn't seem to be a whole lot of agreement here.

Subscribing. D6.

Marleo, please do not subscribe by posting, but use the follow-button on top.

@marleo follow button: http://drupal.org/node/1306444

Its been a while since this was last updated. I would like to see patch #43 applied as well as it also having the additional option of being able to link back to the users profile.

#43 works perfectly for me as well on d7. i wasn't able to display usernames (necessary for my client to use the masquerade module) until this patch was applied.

#43 works so beautifully it makes me cry. Thanks WorldFallz. I would categorize this as a feature request.

I was able to replace the "username" with the "realname" for my View's title without any modification to the module or applying any patches. I'm curious as to if this works for other people too so I have outlined how I was able to accomplish it.

1. Set the title to: Articles by %1
2. Add a relationship for: "Content: Author" and set the relationship to be required.
3. Add an argument (Contextual filter) for: "User: UID" and under "When the filter value is NOT in the URL", select "Provide default value" and then for type select "User ID from URL".
4. In that same argument (User: UID), under "When the filter value IS in the URL or a default is provided", select "Specify validation criteria" and select "User" and then "Allow both numeric UIDs and string usernames".

That should be all you need to create a page or block with a title like "Articles by Jeremy Caldwell".

Screenshots of the Views argument:
http://dl.dropboxusercontent.com/u/3170856/Screenshots/2013/09-September...
http://dl.dropboxusercontent.com/u/3170856/Screenshots/2013/09-September...

@eternalistic - Right, but what we're talking about here is the opposite. What if instead of "Jeremy Caldwell" I need to see "jcaldwell37" for some reason. Currently I can't choose to do that in Views — you get the realname whether you choose realname or username as the field you want outputted.

43: realname-views-username-field-1239478-43.patch queued for re-testing.

Hide all patches except #43

I'd like to commit this to D7, but I do not understand why the patch removes so many lines. Can someone write up a summary and give me a short intro so I can review finally? A repro case would be great.

Have a few reservations re #43:

1) It gets rid of handlers for the realname field which are present in the existing module, hence why patch removing so many lines. For example, if you have a contextual filter for a view using the realname field, will break as the handler is removed by the patch. However, these can be by and large dealt with using existing views handlers, so no need to remove.

2) In terms of whether it makes sense to have 3 fields for username (e.g. 'user: name', 'realname: real name', 'user: name (raw))', I take the point per #40/41 that bit redundant/confusing to maintain all of these. However, as implemented in #43, looks like will potentially cause some existing views to break, as the realname field is effectively lost. So I think best to create an additional raw username field to better support backwards compatibility, but agree better to use 'user: username' instead of 'user: name (raw)' for the raw username, so you don't end up with double (raw) in replacement tokens.

3) In addition, would likely make sense to provide regular set of sort, argument, filter handlers for this new raw username field as well. Additionally, supporting realname substitution in titles/breadcrumbs for both uids and raw usernames is something that will likely be useful, so have included.

Attached patch addresses above, but as my first Drupal patch, I expect it to fail horribly... There are also existing issues with validation of names in contextual filters when RealNames installed which haven't addressed, as will need new plugin to deal with.

PS I'd think that if https://drupal.org/node/1609088 were fixed (which shows no signs of happening, as proposed resolution has potentially significant impacts), could potentially avoid having to touch this in Real Name at all, as you could just use uncheck "Use formatted username" for the name field to access the raw username, which can't at moment as will cause an "Undefined index: uid in views_handler_field->get_value()" error.

#79 this patch fix my problem. Token user:name-raw get real name instead of original username.

The hack in #8 is for Drupal 6. In Drupal 7, it should go like this:

$buser = user_load($row->uid);
return $buser->name;

Otherwise you get an error like this:

Warning: array_flip(): Can only flip STRING and INTEGER values! i DrupalDefaultEntityController->load() (linje 173 af /var/www/vhosts/example.com/includes/entity.inc).

The reason is of course that the api has changed
https://api.drupal.org/api/drupal/modules%21user%21user.module/function/...

For those looking for an immediate solution, but not wanting to patch realname module itself, the workaround in #43 can also be implemented easily via you own custom module:

/**
 * Implements hook_views_data_alter(&$data).
 */
function MY_MODULE_views_data_alter(&$data) {
  
  $data['users']['username'] = array(
    'title' => t('Username'),
    'help' => t("The user or author username."),
    'real field' => 'name',
    'field' => array(
    'handler' => 'views_handler_field_user',
      'handler' => 'views_handler_field',
      'click sortable' => TRUE,
    ),
    'sort' => array(
      'handler' => 'views_handler_sort',
    ),
    'argument' => array(
      'handler' => 'views_handler_argument_string',
    ),
    'filter' => array(
      'handler' => 'views_handler_filter_string',
      'title' => t('Name'),
      'help' => t("The user's actual, raw, username.")
    ),
  );

}

Clear cache, and you will now have a new field available in views (provided you have some sort of relationship to the user entity), called 'User: Username (Username)', which will display the original, raw user->name.

You could also simply implement hook_views_data() directly, but I personally have gone with hook_views_data_alter().

@pocketfluff #83 +1 thanks

The patch in #43 seems to have done the trick for me.

I gratefully thank you!

#83 works fine, though I do think, it should not be necessary.

However, there is a coding mistake:

'field' => array(
    'handler' => 'views_handler_field_user',
      'handler' => 'views_handler_field',
      'click sortable' => TRUE,

The index 'handler' is used twice, but of course the second one will override the first one.

It does work as it is.

we need to fix this bug first

Hi everyone,
I would like to signal a little bug, after I ran the patch in 79.
Now in /admin/config/people/accounts, when I try to change the name for anonymous users, I get this error

The Body does not contain the [user:name-raw] token, which is necessary when using username for login.

I changed it in code, so it was not as big of an issue for me, but it was a bit of a surprise.
I am not sure, whether this issue needs to be addressed here, or in the core User module, or both.

@pocketfluff #83
Here's the module
Don't forget the clear all cache after installation

Just an FYI--

#83/#89 work... but the error prevents the field from being click sortable in views. The corrected code is:

function mymodule_views_data_alter(&$data) {

  $data['users']['username'] = array(
    'title' => t('Username'),
    'help' => t("The user or author username."),
    'real field' => 'name',
    'field' => array(
      'handler' => 'views_handler_field_user',
      'click sortable' => TRUE,
    ),
    'sort' => array(
      'handler' => 'views_handler_sort',
    ),
    'argument' => array(
      'handler' => 'views_handler_argument_string',
    ),
    'filter' => array(
      'handler' => 'views_handler_filter_string',
      'title' => t('Name'),
      'help' => t("The user's actual, raw, username.")
    ),
  );
}

By disabling "Use formatted username" and "Link this field to its user" (due to
#1445404: Views: user name raw display is truncated) on the "User: Name" field settings, you can display the raw username without patches.

See here (#9) for linking the field to the user.

Edit: This starts throwing notices, see #1609088: Undefined index: uid in views_handler_field->get_value() (line 375 of views_handler_field.inc)

#90 worked for me. Thanks guys

Made #90 as a patch for this module.

#91 +1

#91 - works for me

Why is this fundamental different to #79?

Bad news. I reviewed this patch and it seems working. BUT we are doing something wrong here. We try to add a workaround to realname, but I found the root cause of this bug in Views.

The buggy code is in [views/modules/user/views_handler_field_user_name.inc]:

function render_link($data, $values) {
    $account = new stdClass();
    $account->uid = $this->get_value($values, 'uid');
    $account->name = $this->get_value($values);
    if (!empty($this->options['link_to_user']) || !empty($this->options['overwrite_anonymous'])) {
      if (!empty($this->options['overwrite_anonymous']) && !$account->uid) {
        // This is an anonymous user, and we're overriting the text.
        return check_plain($this->options['anonymous_text']);
      }
      elseif (!empty($this->options['link_to_user'])) {
        $account->name = $this->get_value($values);
        return theme('username', array('account' => $account));
      }
    }
    // If we want a formatted username, do that.
    if (!empty($this->options['format_username'])) {
      return format_username($account);
    }
    // Otherwise, there's no special handling, so return the data directly.
    return $data;
  }

What is wrong here? The conditions - very simple.

Why? Views has a checkbox inside usernames field that is named Use formatted username that is enabled by default. If you uncheck this setting the raw-username is still not shown. That is the bug in views. The reason is that the conditons are failing if the checkbox Link this field to its user is enabled. If you disable Link this field to its user and uncheck Use formatted username the raw-username is directly shown.

I will create a patch for views now and move the case than to Views for review.

@hass
This is described in #91 - patch available in #1445404: Views: user name raw display is truncated

Thanks. So this is a duplicate here. After posting I also found that username theming is the root cause. I'm not entirely sure if we should not extend preprocess_username to allow themed username without forced username. At least it should be possible to dissble this behavior with an option like 'format_username' = FALSE.

#91 is the solution for this post ! Just do it!

Indeed, #91 is the solution!