Skip to content

fixed: Prefer display name of user on table UI#18408

Open
kenchan0130 wants to merge 1 commit intogrokability:developfrom
kenchan0130:patch-displayname-on-table
Open

fixed: Prefer display name of user on table UI#18408
kenchan0130 wants to merge 1 commit intogrokability:developfrom
kenchan0130:patch-displayname-on-table

Conversation

@kenchan0130
Copy link

In #18404, I've updated the name displayed in the UI, but I overlooked the parts rendered by JavaScript.

Therefore, in this change, I’ve ensured that elements rendered by JavaScript also prioritize the display name.

@kenchan0130 kenchan0130 requested a review from snipe as a code owner January 7, 2026 14:49
@kenchan0130 kenchan0130 changed the base branch from master to develop January 7, 2026 14:49
return $asset->assigned ? [
'id' => (int) $asset->assigned->id,
'username' => e($asset->assigned->username),
'display_name' => e($asset->assigned->display_name),
Copy link
Author

@kenchan0130 kenchan0130 Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although the polymorphicItemFormatter method of JavaScript is also used in AccessoriesTransformer.php, the transformUserCompact function already passes display_name. Therefore, I determine that the change is only necessary in AssetsTransformer.php.

@swift2512
Copy link

swift2512 commented Jan 8, 2026

@kenchan0130 @snipe could it be that #18408 breaks names shown in 'recent activity' and 'Activity report'? Suddenly, on my test install, upgraded to the latest pull (v8.3.7-95-g542cdef0b), names are empty in dashboard and report, but only for LDAP Sync and only when users present in DB are updated. Newly created users are displayed correctly. (I don't sync Display Names with AD, it always was handled by Snipe-IT.)
image

My other install (v8.3.7-84-g5ddb0b4a55) is not affected by this.

EDIT: If 'Display Name' is manually filled in user profile, only then it is shown in the 'Activity report'. IMHO, taking 'Name' information instead of 'Display name' makes way more sense, because 'Name' format is controlled via 'Admin Settings > Localization', not entered manually or on LDAP Sync.
image

@snipe
Copy link
Member

snipe commented Jan 8, 2026

@swift2512 I'm not seeing what you're seeing, unless I'm misunderstanding.

Screenshot 2026-01-08 at 7 22 31 AM Screenshot 2026-01-08 at 7 23 13 AM Screenshot 2026-01-08 at 7 23 39 AM Screenshot 2026-01-08 at 7 25 14 AM

@swift2512
Copy link

@snipe this only applies to LDAP Sync.

@kenchan0130
Copy link
Author

kenchan0130 commented Jan 8, 2026

IMHO, taking 'Name' information instead of 'Display name' makes way more sense

I understand your point, but my expectation is slightly different:
If a display name is configured, it should take precedence; if not, then fall back to the full name. After all, that's the purpose of a display name.
If this behavior is not currently implemented, I believe we should update the logic in

https://github.com/grokability/snipe-it/blob/master/app/Models/User.php#L211-L216

to reflect this expected behavior.

only applies to LDAP Sync.

When using LDAP Sync, does the display name field in the Snipe-IT database always have a value?
I assume the behavior might depend on that.

GitHub
A free open source IT asset/license management system - grokability/snipe-it

@swift2512
Copy link

swift2512 commented Jan 8, 2026

@kenchan0130 I agree that if Display Name is filled, then it should be used. But this shouldn't break other stuff.
At this point, display of name is broken not only in Activity Report, but also in Asset, Accessory and User History. (License history seems to be unaffected.)

EDIT: Honestly, I don't understand what was the reason behind this fix. I've tested on my main system that wasn't updated to the latest. I've manually set 'Display name' to some value and this value is displayed in:

  • 'Recent activity' on the Dashboard
  • 'Activity report'
  • 'Asset history'
  • 'Accessory history'
  • 'User history'
  • 'Component history'

@kenchan0130
Copy link
Author

case activity page display
empty display name
スクリーンショット 2026-01-08 17 07 25
スクリーンショット 2026-01-08 17 07 08
filled display name
スクリーンショット 2026-01-08 17 07 42
スクリーンショット 2026-01-08 17 04 08

I’ve checked the latest build running on Docker locally, and everything seems to be working fine.
So, if what you’re saying is correct, this might be an LDAP Sync-specific issue. Without more information about that, it seems difficult to pinpoint the problem.

@swift2512
Copy link

Sorry, I've tried different backups, did some testing and find out that my problem is not related to this fix. It's just a bug (or a feature).

// display the username if it's checked out to a user, but don't do it if the username's there already
if (value.username && !value.name.match('\\(') && !value.name.match('\\)')) {
value.name = value.name + ' (' + value.username + ')';
value.name = value.display_name + ' (' + value.username + ')';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd need to check if display_name is set here. That formatter touches a lot of things.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that the ORM function deriving display_name is designed to return full name when display_name is empty.
As I mentioned in #18408 (comment), my understanding is that the recent change ensures the display_name attribute in the JSON will not be empty.

Is your concern that this formatter is (or will be) used outside of AccessoriesTransformer and AssetsTransformer as well?

Also, if a change is needed, are you expecting something like this?

if (value.username && !value.name.match('\\(') && !value.name.match('\\)')) {
    const name = value.display_name ? value.display_name : value.username;
    value.name = name + ' (' + value.username + ')';
}

If this works for you, I can apply the change right away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants