# Guidance on implementing display name precedence

**URL:** https://meta.discourse.org/t/guidance-on-implementing-display-name-precedence/390420
**Category:** Development
**Created:** [December 4, 2025, 2:18pm UTC](https://meta.discourse.org/t/guidance-on-implementing-display-name-precedence/390420 "2025-12-04T14:18:59Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![manut](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/manut/32/485119_2.png) [@manut](https://meta.discourse.org/u/manut)
#### Post date: [December 4, 2025, 2:18pm UTC](https://meta.discourse.org/t/guidance-on-implementing-display-name-precedence/390420/1 "2025-12-04T14:18:59Z")

</div>

I’m digging a bit for the best approach [to implementing this pr-welcome feature](https://meta.discourse.org/t/use-user-names-in-participants-list/390176/12) (I first thought “okay, let’s change this in the one front file where it will solve this proposition”), and stumbled upon the `BasicUserSerializer` (“app/serializers/basic\_user\_serializer.rb”).

So what about adding a `display_name` method in the `User` model, which would return the right value according to the site settings, and use this in all the serializers returning users (or parts), then in all the front components ?

This is a bigger change for sure and _may_ have an impact on performances but seems to be a good start to easily unify the value without performing a check in every ember file.

---

<div class="post-metadata">

### Author: ![keegan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/keegan/32/383395_2.png) [@keegan](https://meta.discourse.org/u/keegan)
#### Post date: [December 4, 2025, 4:15pm UTC](https://meta.discourse.org/t/guidance-on-implementing-display-name-precedence/390420/2 "2025-12-04T16:15:38Z")

</div>

Hi @manut,

Thanks for digging into this and thinking about a broader fix!

However, for this PR I’d recommend simply keeping things focused on the change to the front file and thus fix the change for the calendar participants list.

The broader approach is definitely something worth considering. But, we’ll need to evaluate the approach to use and it’s implications separately since it’s a larger architectural discussion that goes beyond the scope of this fix.

Thanks for being willing to tackle this! Looking forward to your PR!