Problem/Motivation

  • Realname module alters the display name, but at user/1234 the username is shown. This is incorrect.
  • Tons of places in core that show the username, but need to show the users display name.
  • Comments do not show DisplayName for registered users.
  • Security problem as usernames should never shown on websites. With real names you cannot login and try passwords, with a username you can.

Proposed resolution

  • Fix all places where getUsername() or getAccountName() is used, but getDisplayName() should be used.
  • Change core to enable a DisplayName by default. That is why tons of tests are failing because of wrong usage.

Followup tasks

Allow for configurable truncation length of display name: #2767787: Allow custom truncate username settings

User interface changes

Users DisplayName will be properly shown.

API changes

API addition: Entity::getDisplayNameTruncated to get the correct abrivation used in theme_preprocess_username() function.

Data model changes

none

Files: 

Comments

hass created an issue. See original summary.

hass’s picture

hass’s picture

Status: Needs review » Needs work

The last submitted patch, 3: Issue-2629286-by-hass-User-title-does-not-show-displ.patch, failed testing.

hass’s picture

Priority: Normal » Major
Status: Needs work » Needs review
FileSize
3.64 KB

Now with a new display name test. There will be more tests added in follow up cases.

hass’s picture

Just checked with D7 and the real name / display name was not allowed to contain <em> with realname enabled. realname strips html.

Need to check again if core alone allowed it in D7. In this case all places in D8 core need to allow it, too.

hass’s picture

Priority: Major » Critical

Can someone RTBC this, please?

legolasbo’s picture

Priority: Critical » Major
Status: Needs review » Needs work

This does not qualify as critical as far as I know.

There will be more tests added in follow up cases.

If you know there are more relevant cases to be tested, why not add them now?

  1. +++ b/core/modules/user/src/Tests/UserDisplayNameTest.php
    @@ -0,0 +1,68 @@
    +    // Login after the alter hook has been enabled or the username is shown.
    

    'or the username is shown.' I don't know what is meant by this.

  2. +++ b/core/modules/user/src/Tests/UserEntityCallbacksTest.php
    @@ -56,7 +59,7 @@
    -    $this->assertEqual($this->anonymous->getUserName(), '', 'The raw anonymous user name should be empty string');
    +    $this->assertEqual($this->anonymous->getUsername(), '', 'The raw anonymous user name should be empty string');
    

    I don't know what is changed here, but it seems to be unrelated.

hass’s picture

Status: Needs work » Needs review

You could first read the patch and than comment. You can answer your above comments yourself than.

legolasbo’s picture

Status: Needs review » Needs work

I am sorry I gave you the impression I did not read the patch, because I have actually read the patch thoroughly, which raised my questions. What makes you think that I didn't read the patch?

There will be more tests added in follow up cases.

If you know there are more relevant cases to be tested, why not add them now?

I don't think i can answer this question by reading the patch. But the question is valid in my opinion. If you know about more relevant test cases, they should be added no?

Your comment // Login after the alter hook has been enabled or the username is shown. just makes no sense to me. When I look at the code a user is logged in after the hook is enabled. The hook being enabled is obvious and does not require a comment, but nowhere is a page being requested or a render function being called before that comment line. So how can a username be shown?

As for the last question. A changed line ending is the only reason I can think of which would cause that change. Other than that both lines are identical and not changing any functionality. They are therefor unrelated and should be removed.

At first I felt really offended by the way you (aggressively) commented on my review. But after counting to 10 and assuming you might just be having a bad day, I've chosen to answer openly en truthfully like I did above. I do however feel that I should inform you about the way your comment made me feel, so you can maybe adjust your way of responding in the future.

hass’s picture

There will be more tests added in follow up cases.

I linked follow up patches. These will add more patches. I can delete my comment if it helps you ignoring it.

Your comment // Login after the alter hook has been enabled or the username is shown. just makes no sense to me.

That is because you have not understood the patch. One line before is the hook enabled. It is just a note that the order of both lines is important.

The other changed line changes getUserName to getUsername. The function in the class is named getUsername and not getUserName. It is easy to see that this is changed. You said you cannot see a change. I can see this change very well.

legolasbo’s picture

I linked follow up patches. These will add more patches. I can delete my comment if it helps you ignoring it.

I overlooked the Meta issue. With that context I understand the comment and I agree the additional test coverage should be part of their respective issues.

That is because you have not understood the patch. One line before is the hook enabled. It is just a note that the order of both lines is important.

I understand the patch perfectly and also know the order of those lines are important. The comment in it's current form however only adds confusion instead of clarity. How about this?
// We must login after the alter hook as been enabled or the username will be shown instead of the display name.

The other changed line changes getUsername to getUserName. The function in the class is named getUserName and not getUsername.

I have seriously been staring at these two lines for several minutes, both before and after my initial comment, but totally missed that. Thanks for clarifying.

If you improve the comment I'll RTBC the patch.

hass’s picture

Status: Needs review » Needs work

The last submitted patch, 13: Issue-2629286-by-hass-User-title-does-not-show-displ.patch, failed testing.

hass’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 13: Issue-2629286-by-hass-User-title-does-not-show-displ.patch, failed testing.

hass’s picture

Tests are running fine here. There is no php syntax error. No idea what problem the bot has.

vasi’s picture

Status: Needs work » Needs review
FileSize
3.56 KB
430 bytes

I'm not sure why it didn't work, but when I applied your patch I ended up with a missing closing brace. Rerolled with the brace.

effulgentsia’s picture

Issue tags: +Triaged D8 major

Discussed this with @catch, @alexpott, @xjm, and @Cottser, and we agree this is Major.

This is a regression from Drupal 7, and explicitly violates the docs of AccountInterface::getAccountName(), which says Only display this name to admins and to the user who owns this account, whereas "access user profiles" is not an admin-level permission.

hass’s picture

@effulgentsia: can you RTBC the patch, please?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hass’s picture

Status: Needs review » Reviewed & tested by the community
catch’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/user/src/Tests/UserDisplayNameTest.php
@@ -0,0 +1,69 @@
+ * Tests that display name is shown everywhere.

This doesn't test that the display name is shown everywhere.

Also do we really need a new test, or is there an existing login test we could add an assertion to?

hass’s picture

You are not requiring me to test all places in core, aren't you? Maybe the guy who integrated the DisplayName feature should have written it... I just started one to make sure and others will follow up in more cases. This way I can reuse this file.

catch’s picture

Please read the comment I posted again.

The added test only tests one place, we have other tests for that page, so:

Also do we really need a new test, or is there an existing login test we could add an assertion to?

hass’s picture

I have not found any useful place to test this, but I'm open minded to where this could be added. I thought it is better to keep all these DisplayName tests together in on test. It is easier to maintain and extend one place in future than spreading 100 assertions over the whole core code base. At least this was my idea as it is not easy to find otherwise. Not sure if every module should test on it's own if display name works in their module.

This patch here is a start as I have not found a single assertion for display name and it fixes the most important issue and is currently causing a test fail in realname. I cannot get the realname tests green without this patch or I need to comment the code out. I may miss than later to add it back.

I wish it is not contribs job to test if core works properly... :-)

hass’s picture

Any suggestions/answers?

jonathanshaw’s picture

I'm not sure but I think you may not be understanding what @catch meant.

I don't think he's saying "test everywhere, make 100 assertions all over the place". I think he's saying "don't create a new test, take 1 of the existing login tests for that user/ page and add an assertion to that instead".

we [already] have other tests for that [user/] page

is there an existing login test [from among these other tests] we could add an assertion to

However, I could not see a test in the user module that tested the basic contents of the user/userID page. I assume this is my own ignorance and I've overlooked something, but if you can't find the file with the basic tests for this page either, maybe you could report that to @catch and see what he advises. Surely is must exist somewhere.

hass’s picture

Status: Needs work » Reviewed & tested by the community

However, I could not see a test in the user module that tested the basic contents of the user/userID page. I assume this is my own ignorance and I've overlooked something

No you have not overlooked anything. There is NO test yet. This one will be the first. I have no idea where I could add it to. Nothing makes sense to me. If nobody can point me to a useful place this is the right one.

hass’s picture

Status: Reviewed & tested by the community » Needs work

As Drupal core is a mess if it comes to testing DisplayName I see only one other solution. We need to enable 'user_hooks_test' module with core - always. Otherwise every module that shows a display name need to enable this module by itself what is quite stupid. This affects very many places in core.

hass’s picture

Let's see how seriously this will break core tests.

hass’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 31: Issue-2629286-by-hass-Enable-display-name.patch, failed testing.

hass’s picture

Uh, really? Only 30 fails? Let's add all core bugs now and see how many fails this bugfixes may have. This patch incorporates #2658602: User picture alt text should user display name to fix all the tons of bugs in a bunch.

hass’s picture

Title: User title does not show display name » Fix the DisplayName mess

Changing title.

Status: Needs review » Needs work

The last submitted patch, 34: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Status: Needs work » Needs review
FileSize
48.12 KB

Status: Needs review » Needs work

The last submitted patch, 37: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

I'd like to note that testSessionSaveRegenerate() already has the test we have looked for, BUT it has not catched the bug reported here first.

Status: Needs review » Needs work

The last submitted patch, 39: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Every fix seems to brings up more unseen bugs... really worse test coverage.

Status: Needs review » Needs work

The last submitted patch, 41: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Status: Needs review » Needs work

The last submitted patch, 43: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Status: Needs review » Needs work

The last submitted patch, 45: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Status: Needs work » Needs review
FileSize
65.32 KB

Status: Needs review » Needs work

The last submitted patch, 47: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Issue summary: View changes
Issue tags: +Security improvements

Rewritten case summary.

hass’s picture

Issue summary: View changes
hass’s picture

Issue summary: View changes
hass’s picture

hass’s picture

hass’s picture

The last submitted patch, 52: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

The last submitted patch, 53: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 54: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

Status: Needs work » Needs review
FileSize
71.14 KB

Status: Needs review » Needs work

The last submitted patch, 58: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

hass’s picture

hass’s picture

The last submitted patch, 60: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 61: Issue-2629286-by-hass-Fix-the-DisplayName-mess.patch, failed testing.

gnuget’s picture

Here a #61's reroll.

I will try to fix the test which are still failing.

gnuget’s picture

Assigned: Unassigned » gnuget

I've been working today on this.

+++ b/core/profiles/testing/testing.info.yml
@@ -9,6 +9,8 @@ dependencies:
+  # Make sure DisplayName is always enabled and properly tested.
+  - user_hooks_test

I do not agree with this, even if it is stupid like #30 said if this module is enabled by default this will make the output in certain tests be unexpected and will confuse developers when they write new tests because some <em> tags will appear in the DisplayName.

If every module which uses display name enable this module at least it will give an insight why the displayname has some extra tags.

I will try to provide a patch which not require this module by default.

hass’s picture

Hey, the sense of this patch is to show WHERE dispayname is broken. This is why i wrote this. Developers need to expect the display name AND html. Currently they often do not and THIS is the problem!!!

gnuget’s picture

Assigned: gnuget » Unassigned
Status: Needs work » Needs review
FileSize
3.06 KB
76.28 KB

Hi hass

Hey, the sense of this patch is to show WHERE dispayname is broken. This is why i wrote this. Developers need to expect the display name AND html.
Currently they often do not and THIS is the problem!!!

You are right, I left the user_hooks_test in the testing.info.yml file so we know which tests we need to fix (thanks!)

I hit a wall here:

    \Drupal::state()->set('user_hooks_test_user_format_name_alter_safe', TRUE);
    $this->drupalPostForm('node/' . $this->node->id(), $edit, t('Preview'));
    $this->assertTrue($this->webUser->getDisplayName() instanceof MarkupInterface, 'Username is marked safe');
    $this->assertNoEscaped($this->webUser->getDisplayName());
    $this->assertRaw($this->webUser->getDisplayName());
    \Drupal::state()->set('user_hooks_test_user_format_name_alter_safe', FALSE);

Basically, the test expect the "<em></em>" be wrapping the display name BUT if the displayname is longer than 20 characters the getDisplayNameTruncated will remove the last leaving something like: <em>Firstname3… which makes me wonder if the getDisplayNameTruncated should strip the html tags before to truncate the string and if we should rewrite the test above.

I attached my progress so far.

Status: Needs review » Needs work

The last submitted patch, 67: fix_the_displayname_mess-2629286-67.patch, failed testing.

hass’s picture

That is something I wasted hours with... if not 2 days. No idea how to fix this test. Since the EM is checkplained there should be no issue for now.

A follow up issue should be consitency of the DisplayName. Tons of places strip HTML and others do not. This is very strange. But we can and should do this in followup's. It may require many theme changes, but not sure yet. In general HTML is supported in display name. Maybe we need to fix all occurrences where tags are stripped. Need some core maintainer to decide on this.

I also have posted a patch in #2767787: Allow custom truncate username settings that disables display name truncating. I'm in high favor to remove truncating by default and only enable it where it is required. Something that may need some discussion...

hass’s picture

  1. +++ b/core/modules/comment/src/Tests/CommentPreviewTest.php
    @@ -45,6 +45,7 @@ function testCommentPreview() {
    +    \Drupal::service('module_installer')->install(['user_hooks_test']);
    

    that looks strange... that should be installed by default.

  2. +++ b/core/modules/user/src/Entity/User.php
    @@ -383,7 +383,7 @@ public function getDisplayName() {
    +      $name = Unicode::truncate((string) $name, 15, FALSE, TRUE);
    

    How is it possible that $name is no string?

  3. +++ b/core/modules/user/src/Tests/UserAdminTest.php
    @@ -178,7 +178,7 @@ function testNotificationEmailAddress() {
    +    $subject = strip_tags('Account details for ' . $user->getDisplayName() . ' at ' . $system->get('name') . ' (pending admin approval)');
    

    I would better only strip on the display name

gnuget’s picture

  1. that looks strange... that should be installed by default

    Yeah, it is weird, not sure why in this case is not there by default, I will check why.

  2. How is it possible that $name is no string?

    That is because of this:

    if (\Drupal::state()->get('user_hooks_test_user_format_name_alter_safe', FALSE)) {
            $name = SafeMarkup::format('@display-name', array('@display-name' => 'Firstname' . $uid . ' Lastname' . $uid));
    }
    

    SafeMarkup::format() returns an instance of MarkupInterface

  3. I would better only strip on the display name

    True, I will fix that in my next patch.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ekes’s picture

Hi,

Just run into this one with some tests on a site with the a changed display name.

Reading up, I was wondering - honest question, I've not delved deeply into the different usages of DisplayName - could the issue and patch be broken into two (or three)? One of them RTBC as lots of them are trivial fixes that might as well go in, and one detailing the problems with different usages.

hass’s picture

I fear core developers will only commit with full test coverage... just a guess.

ekes’s picture

I agree changing the active code without tests to cover it wouldn't be good. Could those case be spun off into another issue that actually details what the problem is. But plenty of this patch should be good no?

The core _tests_ are presently broken. If you implement a change to getDisplayName() there's red. There are tests that use getUserName() in them, which pass only because the output is the same as getDisplayName(); but they should be using getDisplayName() because that's being put into the strings. This patch includes those changes, can't see any reason they shouldn't go in already. Committing changes to the tests already would be an improvement?

Also if there are some changes to the active code, cleaning up other places that it's wrong - with tests - would be an improvement too?

Then it's the complicated bits that could be fleshed out? Like I say, a thought.

hass’s picture

I think they will complain why we need to commit this patch as we are not proving the bugs by running the failing tests. This patch here shows all the already existing bugs... not sure how you'd like to split it.

ekes’s picture

Interesting question. Guess to prove the tests fail you have to implement a test module that changes getDisplayName so it's not the same as getUserName.

Anyway if it's not going to speed up getting fixes in, doesn't matter.

Mile23’s picture

Title: Fix the DisplayName mess » Use getDisplayName() for user names consistently
Issue summary: View changes
FileSize
76.35 KB

This might be enough of a change to bump up to 8.3.x, but it's a major bug so leaving it at 8.2.x.

I think it's a reviewable size as-is, though it is big.

Just a couple things related to the truncated name:

  1. +++ b/core/lib/Drupal/Core/Session/AccountInterface.php
    @@ -146,6 +146,18 @@ public function getAccountName();
       /**
    +   * Returns the truncated display name of this account.
    +   *
    +   * @see getDisplayName()
    +   *
    +   * @return string|\Drupal\Component\Render\MarkupInterface
    +   *   Either a string that will be auto-escaped on output or a
    +   *   MarkupInterface object that is already HTML escaped. Either is safe
    +   *   to be printed within HTML fragments.
    +   */
    +  public function getDisplayNameTruncated();
    

    Either add a length parameter or document the truncated length. But really add a length parameter that defaults to 20. :-)

  2. +++ b/core/modules/user/user.module
    @@ -471,10 +471,9 @@ function template_preprocess_username(&$variables) {
    +  $name  = $account->getDisplayNameTruncated();
    +  $variables['name_raw'] = $account->getDisplayName();
       if (Unicode::strlen($name) > 20) {
    -    $name = Unicode::truncate($name, 15, FALSE, TRUE);
         $variables['truncated'] = TRUE;
    

    If you have a way to pass in the truncated length, then you can do that here and know that 20 is the biggest non-truncated name without trusting.

Here's a straight re-roll of #67.

Mile23’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 78: 2629286_78.patch, failed testing.

hass’s picture

I think we should not mix this up. I 100% agree with you that the length should be configurable, but as of now it is not and this may end in an endless discussion. See #2767787: Allow custom truncate username settings for this.

hass’s picture

Mile23’s picture

Issue summary: View changes

OK, so #2767787: Allow custom truncate username settings is a follow-up. That's a D7 issue, btw.

Still needs passing tests here.

mohit_aghera’s picture

Assigned: Unassigned » mohit_aghera
ifrik’s picture

Assigned: mohit_aghera » Unassigned

Mohit_aghera,

great that you want to contribute to this issue, but there is no need to assign this to you.
Even though the issue tracker technically allows people to assign issues, this feature is generally not used in order to encourage everybody to contribute.
And as you can see in this case: there are several people actively working on the issue.

If you want to contribute: please write that into a comment. Don't claim issues for yourself. I'll unassign you.

(And to anybody committing this later: Don't credit me in the issue commit. I'm just writing a note.)

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
78.47 KB

Here is straight re-roll of #78 for initial testing

Status: Needs review » Needs work

The last submitted patch, 87: 2629286_87.patch, failed testing.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
77.98 KB
586 bytes

Uploading patch with initial try to fix test case failures.

Status: Needs review » Needs work

The last submitted patch, 89: 2629286_89.patch, failed testing.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
78.55 KB
2.89 KB

Updating relevant method names.

Status: Needs review » Needs work

The last submitted patch, 91: 2629286_91.patch, failed testing.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
78.76 KB
450 bytes

Added missing namespace which was causing fatal errors.

Status: Needs review » Needs work

The last submitted patch, 93: 2629286_92.patch, failed testing.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
78.76 KB
450 bytes

Status: Needs review » Needs work

The last submitted patch, 95: 2629286_94.patch, failed testing.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
79.16 KB

Re-rolling patch again as it was not getting applied after recent test case changes.

Status: Needs review » Needs work

The last submitted patch, 97: 2629286_97.patch, failed testing.

DuaelFr’s picture

Thank you for your contribution. Beware of duplication with #2801645: Use \Drupal\user\UserInterface::getDisplayName() on user pages instead of the plain User::getUsername() , though.
I'm not confident enough to decide which of your issues should be closed in favor of the other. Could you have a look there and see how you can converge?

idebr’s picture

gaurav.kapoor’s picture

Status: Needs work » Needs review
FileSize
132.15 KB

Status: Needs review » Needs work

The last submitted patch, 101: 2629286-101.patch, failed testing.

gaurav.kapoor’s picture

Status: Needs work » Needs review
FileSize
132.09 KB

Status: Needs review » Needs work

The last submitted patch, 103: 2629286-103.patch, failed testing.

hass’s picture

What are you doing there? Your patch is not really good and has tons of bugs introduced. Without reviewing your patch in detail - code like below can only incorrect. This can only be getAccountName() if you login to something, but you need to verify every occurence one by one.

-    $this->basicAuthGet($url, $account->getUsername(), $account->pass_raw);
-    $this->assertText($account->getUsername(), 'Account name is displayed.');
+    $this->basicAuthGet($url, $account->getDisplayName(), $account->pass_raw);
+    $this->assertText($account->getDisplayName(), 'Account name is displayed.');
-    $this->basicAuthGet($url, $account->getUsername(), $account->pass_raw);
+    $this->basicAuthGet($url, $account->getDisplayName(), $account->pass_raw);

You cannot simply search and replace getUsername with getDisplayName(). In most if not all - cases this is incorrect. This case is to fix places where the username is shown, but displayname should shown. Not everywhwere is this true.

Go back to #97, please.

hass’s picture

That looks Like a bad idea as usernames cannot changed, but display names can. If we log something it should be the username or we lose the reference of the log if a user changes it's getDisplayName.

if (!$message->isPersonal()) {
       $this->logger->notice('%sender-name (@sender-from) sent an email regarding %contact_form.', array(
-        '%sender-name' => $sender_cloned->getUsername(),
+        '%sender-name' => $sender_cloned->getDisplayName(),
hass’s picture

Reroled the patch.

Status: Needs review » Needs work

The last submitted patch, 107: Issue-2629286-by-hass-Use-getDisplayName-for-user-na.patch, failed testing.

hass’s picture

Status: Needs review » Needs work

The last submitted patch, 110: Issue-2629286-by-hass-Use-getDisplayName-for-user-na.patch, failed testing.

hass’s picture

hass’s picture

The last submitted patch, 112: Issue-2629286-by-hass-Use-getDisplayName-for-user-na.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 113: Issue-2629286-by-hass-Use-getDisplayName-for-user-na.patch, failed testing.

hass’s picture

Issue summary: View changes