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

fix(mentions): fix wrong user list given to mentions model #16615

Merged
merged 1 commit into from
Oct 29, 2024

Conversation

jrainville
Copy link
Member

What does the PR do

Fixes #16602

This was broken when we refactored the members to use a single model for public channels. Those public channels then didn't have any members in their model they used for suggestions. This is fixed by putting the logic in the UsersStore and reusing that store whenever we need a list of the members.

Affected areas

ChatColumnView and ChatView

Architecture compliance

Screenshot of functionality (including design for comparison)

mentions.webm

I forgot to show in the video, but they work in the Edit message input too.

image

Impact on end user

Fixes the mentions

How to test

Test the mentions in different types of chats and scenarios (1-1, group, community channel (public or not), edit message.

Risk

Tick one:

  • Low risk: 2 devs MUST perform testing as specified above and attach their results as comments to this PR before merging.
  • High risk: QA team MUST perform additional testing in the specified affected areas before merging.

Worst case the mentions are still missing in some context

@jrainville
Copy link
Member Author

@caybro you've been randomly selected to test this fix

return chatCommunitySectionModule.membersModel
}
return usersModule ? usersModule.model : null
}
Copy link
Member Author

Choose a reason for hiding this comment

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

I moved the logic from ChatView to this store and reused the store whenever we need to get the right member model

@status-im-auto
Copy link
Member

status-im-auto commented Oct 25, 2024

Jenkins Builds

Click to see older builds (7)
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ 8fd4477 #1 2024-10-25 14:37:57 ~7 min tests/nim 📄log
✔️ 8fd4477 #1 2024-10-25 14:39:17 ~8 min macos/aarch64 🍎dmg
✔️ 8fd4477 #1 2024-10-25 14:44:20 ~13 min tests/ui 📄log
✔️ 8fd4477 #1 2024-10-25 14:47:30 ~16 min macos/x86_64 🍎dmg
✔️ 8fd4477 #1 2024-10-25 14:48:48 ~18 min linux/x86_64 📦tgz
✔️ 8fd4477 #1 2024-10-25 14:52:34 ~21 min linux-nix/x86_64 📦tgz
✔️ 8fd4477 #1 2024-10-25 14:58:47 ~27 min windows/x86_64 💿exe
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ 4e0d6e9 #2 2024-10-29 14:39:32 ~6 min macos/aarch64 🍎dmg
✔️ 4e0d6e9 #2 2024-10-29 14:40:20 ~7 min tests/nim 📄log
✔️ 4e0d6e9 #2 2024-10-29 14:44:15 ~10 min macos/x86_64 🍎dmg
✔️ 4e0d6e9 #2 2024-10-29 14:46:50 ~13 min tests/ui 📄log
✔️ 4e0d6e9 #2 2024-10-29 14:50:40 ~17 min linux/x86_64 📦tgz
✔️ 4e0d6e9 #2 2024-10-29 14:52:04 ~18 min linux-nix/x86_64 📦tgz
✔️ 4e0d6e9 #2 2024-10-29 15:01:24 ~28 min windows/x86_64 💿exe
✔️ 57a5a66 #3 2024-10-29 17:24:26 ~6 min macos/aarch64 🍎dmg
✔️ 57a5a66 #3 2024-10-29 17:25:12 ~7 min tests/nim 📄log
✔️ 57a5a66 #3 2024-10-29 17:28:41 ~10 min macos/x86_64 🍎dmg
✔️ 57a5a66 #3 2024-10-29 17:31:04 ~13 min tests/ui 📄log
✔️ 57a5a66 #3 2024-10-29 17:34:55 ~17 min linux/x86_64 📦tgz
✔️ 57a5a66 #3 2024-10-29 17:37:21 ~19 min linux-nix/x86_64 📦tgz
✔️ 57a5a66 #3 2024-10-29 17:44:35 ~26 min windows/x86_64 💿exe

Copy link
Member

@caybro caybro left a comment

Choose a reason for hiding this comment

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

LGTM

can't say it's not complicated, so much JS code there :(

@jrainville jrainville linked an issue Oct 28, 2024 that may be closed by this pull request
Copy link
Contributor

@alexjba alexjba left a comment

Choose a reason for hiding this comment

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

LGTM for this HF. 👍
I think there are some things we can improve for the master branch

@@ -175,21 +175,17 @@ StatusSectionLayout {
rightPanel: Component {
id: userListComponent
UserListPanel {
readonly property var usersStore: ChatStores.UsersStore {
Copy link
Contributor

Choose a reason for hiding this comment

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

WDYT of passing the store, just like every other store available here, from the AppMain? Would be nice not to use these context properties here. I know the context properties are available in this component, but I wouldn't extend any impl that relies on this to make it easier for a future refactoring.

Copy link
Contributor

Choose a reason for hiding this comment

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

Or even better, forward just the usersModel if it's an option?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure I understand your suggestion. The usersModule is for this chat in particular. We cannot use UsersStore in AppMain, because it wouldn't have access to chatContentModule

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it! The suggestion was not to use the context property in the ChatView.

property var usersModule

readonly property var usersModel: usersModule ? usersModule.model : null
readonly property var usersModel: {
Copy link
Contributor

Choose a reason for hiding this comment

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

The usersModule.model provides all contacts and the chatCommunitySectionModule.membersModel provides a list of community members?

Copy link
Member Author

Choose a reason for hiding this comment

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

Pretty much. This is a change I did lately where I put a User's module in the section module itself, to hold all the members of the community.

The reason for that being all the public channels of a community contain all the members of a community and so we were duplicating the same member model in all of them, and they were big.

So when a community channel is public (no token permissions), we instead use the section's member model. It saves memory and also improves performance when switching from one public channel to another, because the model doesn't change.

Copy link
Member

@caybro caybro left a comment

Choose a reason for hiding this comment

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

Tested, works fine! 🚀

@jrainville jrainville force-pushed the fix/no-suggested-mentions branch from 8fd4477 to 4e0d6e9 Compare October 29, 2024 14:32
Fixes #16602

This was broken when we refactored the members to use a single model for public channels. Those public channels then didn't have any members in their model they used for suggestions.
This is fixed by putting the logic in the UsersStore and reusing that store whenever we need a list of the members.
@jrainville jrainville force-pushed the fix/no-suggested-mentions branch from 4e0d6e9 to 57a5a66 Compare October 29, 2024 17:17
@jrainville jrainville merged commit 9a74a77 into release/2.31.x Oct 29, 2024
9 checks passed
@jrainville jrainville deleted the fix/no-suggested-mentions branch October 29, 2024 18:06
jrainville added a commit that referenced this pull request Oct 29, 2024
Fixes #16602

This was broken when we refactored the members to use a single model for public channels. Those public channels then didn't have any members in their model they used for suggestions.
This is fixed by putting the logic in the UsersStore and reusing that store whenever we need a list of the members.
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.

Suggested mentions only lists "everyone"
4 participants