-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
"username_display": "displayname"
does not work
#149
Comments
+1 |
Actually updating to 0.0.9 did solve it. (whoops) |
But the latest release is 0.0.8... |
v0.0.8 was released Jul 8, this issue was made Aug 20. Any progress would be on the v0.0.9 alpha, which is the git HEAD. There is some inconsistency whether or not Possibly relevant logs:
|
Removing the relevant session token fixes it for the rest of the session. |
Maintainer of that repo. I updated the repo to git HEAD to solve this. It required removal of session token like u20n says, but it works on latest repo. Downgraded afterwards to confirm confirm 0.0.8's |
I believe I found the source of the display_name inconsistency in v0.0.9 alpha while working on #168. The UI uses the This should be fixable by populating the |
Fixes ulyssa#149 ClientWorker::get_room extends the returned FetchedRoom to include RoomMembers from Room::members_no_sync. This allows RoomState to update the RoomInfo's display_names, like it does with name and tags.
Fixes ulyssa#149 ClientWorker::get_room extends the returned FetchedRoom to include RoomMembers from Room::members_no_sync. This allows RoomState to update the RoomInfo's display_names, like it does with name and tags. Thanks to <benjamin@computer.surgery> for finding the source of the bug in that issue. It was mentioned that it might be problematic to iterate over all members of large rooms. The largest room I had available to test this was only about 200 members, but it seemed fine.
Fixes ulyssa#149 The display_names only got populated from the OriginalSyncRoomMemberEvent. When opening an already synced room, display_names is not populated. ClientWorker::get_room extends the returned FetchedRoom to include RoomMembers from Room::members_no_sync. This allows RoomState::new to populate the RoomInfo's display_names. Thanks to <benjamin@computer.surgery> for finding the source of the bug in that issue. It was mentioned that it might be problematic to iterate over all members of large rooms. The largest room I had available to test this was only about 200 members, but it seemed fine.
Fixes ulyssa#149 The display_names were only populated from the OriginalSyncRoomMemberEvent. When opening an already synced room, display_names is not populated. The ChatStore's `need_load` is changed to a hashmap with OwnedRoomIds as keys and a bitmask of "needs" as value. The "need" thus can be `MESSAGES` or `MEMBERS`. The task that loads messages now also loads members, if that flag is set for the room, which is done when opening a window. Thanks to <benjamin@computer.surgery> for finding the source of the bug in that issue.
Fixes ulyssa#149 The display_names were only populated from the OriginalSyncRoomMemberEvent. When opening an already synced room, display_names is not populated. The ChatStore's `need_load` is changed to a hashmap with OwnedRoomIds as keys and a bitmask of "needs" as value. The "need" thus can be `MESSAGES` or `MEMBERS`. The task that loads messages now also loads members, if that flag is set for the room, which is done when opening a window. Thanks to <benjamin@computer.surgery> for finding the source of the bug in that issue.
Fixes ulyssa#149 The display_names were only populated from the OriginalSyncRoomMemberEvent. When opening an already synced room, display_names is not populated. The ChatStore's `need_load` is changed to a hashmap with OwnedRoomIds as keys and a bitmask of "needs" as value. The "need" thus can be `MESSAGES` or `MEMBERS`. The task that loads messages now also loads members, if that flag is set for the room, which is done when opening a window. Thanks to <benjamin@computer.surgery> for finding the source of the bug in that issue.
Fixes ulyssa#149 The display_names were only populated from the OriginalSyncRoomMemberEvent. When opening an already synced room, display_names is not populated. The ChatStore's `need_load` is changed to a hashmap with OwnedRoomIds as keys and a bitmask of "needs" as value. The "need" thus can be `MESSAGES` or `MEMBERS`. The task that loads messages now also loads members, if that flag is set for the room, which is done when opening a window. Thanks to <benjamin@computer.surgery> for finding the source of the bug in that issue.
OS: openSUSE Tumbleweed
Iamb version: 0.0.8 (installed from OBS repo home:smolsheep)
Logs (level: debug): https://paste.opensuse.org/493c0afc2a1e
Config:
Thank you very much for your work! Unfortunately, i've faced one issue.
Iamb just puts Matrix ID (
@user:example.com
) instead of display names. Tried in rooms with from 10 to 500 members and even in dms.It's very uncomfortable in rooms with bridges to other messengers, because every username transforms into sth like
@telegram_12345678910:t2bot.io
.Thanks for attention.
The text was updated successfully, but these errors were encountered: