Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usernames are shown instead of real names in reactions #27378

Closed
banderosss opened this issue Nov 28, 2022 · 11 comments · Fixed by #27383
Closed

Usernames are shown instead of real names in reactions #27378

banderosss opened this issue Nov 28, 2022 · 11 comments · Fixed by #27383

Comments

@banderosss
Copy link

Description:

The setting UI_use_real_name is ignored in the desktop app and browser, usernames are always shown for reactions.
In other interface elements real names are displayed.

Steps to reproduce:

  1. Go to Administration - Settings - Layout - User Interface
  2. Set Use Real Name

Expected behavior:

Real names must be shown.

Actual behavior:

image
image

Server Setup Information:

  • Version of Rocket.Chat Server: 5.3.2
  • Operating System: Centos 7
  • Deployment Method: snap
  • Number of Running Instances: 1
  • NodeJS Version: v14.19.3
  • MongoDB Version: 4.4.15 / wiredTiger

Client Setup Information

  • Desktop App or Browser Version: Google Chrome 107.0.5304.108, (64 bit)/Rocket.Chat3.8.12/3.8.13/3.8.14
  • Operating System: Windows 10 Pro/Windows 7 Pro
@SaiRev0
Copy link

SaiRev0 commented Nov 29, 2022

Is the issue resolved, if not I would like to work on it?

@Gummikavalier
Copy link

I asked about the status of reaction name fixes in the community meeting few weeks ago.

The issue is complex; Showing real names requires more queries to be made and is considered too expensive (database queries) in the situations where some message has lots of reactions.
It is a common scenario that in big companies on big channels hundreds and even thousands of reactions can be shown on one single page for every user in the company. For instance when polls are arranged by letting users to choose their answer using reactions to the message. Querying all the real names based on the listed usernames would cause excess load to both client end as well as to the database. This is a load matter.

The usernames in the reactions are written directly into the original message database entry itself, where the message otherwise belongs to original message sender. This one is a security sensitive matter.

In situations where the names of people change (marital status change for instance), the real name change needs to be written in all places in the database where it has been implemented as a string attachment to the username. This one is both security as well as load matter.

In the past when the reactions still worked without issues using real names, the real names were either written directly into the message bit unsafe and in certain situations costly way, or were just plain resolved with the brutely costly way.

Both secure and cost effective method is required to fix the issue and the devs have already tried it without complete success at this.

This was not mentioned particularly, but I think the devs might not be willing to let others to work on the issue for above reasons. (Unless the solution takes into account all of its prerequisites.)

@SaiRev0
Copy link

SaiRev0 commented Nov 30, 2022

Thanks for the insides @Gummikavalier. I understand the situation, and from your message, I also think that others working on this issue will not be good. So, no problem there. I hope this issue resolves soon, best of luck from my side.

If there is some other issue you think I can work on, please let me know.

ThankYou
SaiRev

@banderosss
Copy link
Author

Thanks for your detailed answer @Gummikavalier. But I have a question. How often, even in very large companies, marital status, gender or real names of chat participants change?

@Gummikavalier
Copy link

@banderosss As a load change issue the name change is not that big question in closed systems I admit. Namely the biggest load issues would probably come from individuals in systems that allow changing ones name under profile, and someone would start constantly doing that for griefing purposes. Also such system would need to be very old with a huge message and reaction history. My example was bad for load issues indeed.

But from the security point of view it could bite very fast if harder to sanitize character sets of real names were used to write into the other people's messages directly. This is just one security implication example I can think of. You may have to build some kind of placeholder structure for this if you want to support all languages in the world, and then you are again back at the original performance issue by doubling the amount of the queries in all situations.

@henit-chobisa
Copy link
Contributor

Hey there @Gummikavalier, what an amazing explanation up there! I would love to if we can have a chat someday,
Actually, you are 100% correct with your points but I want to state that the problem is not what you highlighted.

  1. About the Database queries, the name and the username is globally available by means of meteor and there is no problem in fetching the it.

  2. Each message consist of a reactions object, which is of type INDEX SIGNATURE, consisting of name of reaction corresponding to names array, usernames array. Hence, The user_real_name setting is considered in the schema itself.

  3. There is a method in the Chat Messages schema, responsible for updating the reactions, in a particular message, which eventually updates the whole reactions object than a particular reaction, so eventually for every new reaction you have to update the message, irrespective of the USE_REAL_NAME setting.

Actually the issue is that, at some places, the developers have not considered the names parameter and have not inserted the name of the username in the names array of the reactions, which is leading to unavailability of name for a particular reaction, in addition to this, there is also a mistake that, at one point of code, the INDEX SIGNATURE datatype is miss considered as An Array which lead to obstruct the Use_Real_Name every time and hence, nobody noticed it yet.

Now, I have fixed everything that I am talking about, I would be very happy if you can go through the reasoning I gave in the PR @banderosss @SaiRev0

Thanks 😄

@Gummikavalier
Copy link

Gummikavalier commented Dec 5, 2022

@henit-chobisa Me humbly bows in front of your reasoning! Thanks! 🙌

@debdutdeb Raising awareness of the devs. Would this work on the issue?

@debdutdeb
Copy link
Member

Hey Toni,

I'm aware of this exact issue and Henit's PR. I'm due a discussion with our eng lead (who'll be back tomorrow) on some further points.

Atm I'm thinking about going the extra mile and feature complete instead of half-patching. And hopefully Henit will be working on this, together with us.

It's gonna take a little while (Henit will keep the community updated I'm sure ;)) - hopefully this isn't a major issue for most and a little delay to feature completion is acceptable. But absolutely we're aware of this and will make sure this gets fixed.

Can't promise a timeline, but given how my discussion goes with Diego, we might target 6.0 for this.

@tamasgal
Copy link

What is the status of this issue? We are having hundreds of angry users after we switched to another LDAP where the usernames are random letters 😉

Btw. I first thought I understand the implications of displaying the name instead of the username but now that I discovered that the mobile RocketChat app for iOS actually displays the real names instead of the usernames when touch-holding the reactions, I am wondering why it's implemented there, but not in the web GUI. Apparently the functionality is already there and works (at least for us) fine, with hundreds of users.

@Manish-rai-dev
Copy link

I can solve this issue assign the issue to me.

@hugocostadev
Copy link
Contributor

Closing this issue duplicated of: #20841


Questions? Help needed? Feature Requests?

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

Successfully merging a pull request may close this issue.

8 participants