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

Unify community members lists into one #16508

Open
wants to merge 7 commits into
base: perf/dont-update-whole-community
Choose a base branch
from

Conversation

jrainville
Copy link
Member

What does the PR do

Fixes #16433

In the section model, we used to have 4 models for all the different types of members (joined, request pending, request declined and banned)

Now they are united in one model (allMembers) and only in QML we filter them in four different models.

I also fixed some bugs that flew under the radar, like the fact that we never update the member's state when it changed, we used to just move them from one model to another.

Known issue

The number of members in the profile showcase will be wrong for communities where you are an admin.

This is because since we united all members in one model, the count of the members is higher than the actual joined members.

I tried doing the same trick I did in ChatLayout where I create a SFPM to get the joined members and use that for the count, but it doesn't seem to work with the way we use those models. It would either break or always show 0.

I can open an issue later, but it's a very minor issue IMO.

Affected areas

  • Community members list (for admins, the list on the right of the community is a different model).
  • Member count of the community in the top bar, portal and profile showcase.

Architecture compliance

Impact on end user

Nothing, the UX is all the same, this is just a refactor to simplify the handling of members.

How to test

  • Check that the admin member lists contain the right members and update correctly when one member is added, removed, banned, declined, accepted, etc.
  • Check the profile showcase and portal for the number of members and active users (see known issues for the profile showcase)

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 scenario would be one of the list of members in the admin panel to be erroneous until a restart

@jrainville jrainville requested a review from a team October 10, 2024 20:06
sectionItemCopy.pendingMemberRequests = pendingMemberRequests
sectionItemCopy.declinedMemberRequests = declinedMemberRequests
return sectionItemCopy
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This little trick makes it so that I don,t have to modify every place we used members. I basically put the right model inside the right property name.

Let me know if there is a cleaner way to do it with some sort of SFPM.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think there's an easy way; that said, I think this is overkill. For most common properties, I think you can continue using sectionItemModel and only where you need a specific member model, you should pass one of the filtered SFPM models instead of the members

@status-im-auto
Copy link
Member

status-im-auto commented Oct 10, 2024

Jenkins Builds

Click to see older builds (7)
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ e0a2794 #1 2024-10-10 20:12:50 ~6 min macos/aarch64 🍎dmg
✔️ e0a2794 #1 2024-10-10 20:13:09 ~6 min tests/nim 📄log
✔️ e0a2794 #1 2024-10-10 20:18:17 ~12 min tests/ui 📄log
✔️ e0a2794 #1 2024-10-10 20:19:41 ~13 min macos/x86_64 🍎dmg
✔️ e0a2794 #1 2024-10-10 20:21:14 ~15 min linux-nix/x86_64 📦tgz
✔️ e0a2794 #1 2024-10-10 20:23:26 ~17 min linux/x86_64 📦tgz
✔️ e0a2794 #1 2024-10-10 20:28:43 ~22 min windows/x86_64 💿exe
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ 4916ac4 #2 2024-10-11 16:46:28 ~4 min macos/aarch64 🍎dmg
✔️ 4916ac4 #2 2024-10-11 16:49:18 ~7 min tests/nim 📄log
✔️ 4916ac4 #2 2024-10-11 16:53:57 ~12 min macos/x86_64 🍎dmg
4916ac4 #2 2024-10-11 16:54:07 ~12 min tests/ui 📄log
✔️ 4916ac4 #2 2024-10-11 16:57:50 ~15 min linux-nix/x86_64 📦tgz
✔️ 4916ac4 #2 2024-10-11 16:58:07 ~16 min linux/x86_64 📦tgz
✔️ 4916ac4 #2 2024-10-11 17:02:56 ~20 min windows/x86_64 💿exe
✔️ 6ef9f85 #3 2024-10-11 17:29:31 ~4 min macos/aarch64 🍎dmg
✔️ 6ef9f85 #3 2024-10-11 17:32:23 ~7 min tests/nim 📄log
✔️ 6ef9f85 #3 2024-10-11 17:36:24 ~11 min macos/x86_64 🍎dmg
6ef9f85 #3 2024-10-11 17:37:08 ~12 min tests/ui 📄log
✔️ 6ef9f85 #3 2024-10-11 17:39:37 ~14 min linux-nix/x86_64 📦tgz
✔️ 6ef9f85 #3 2024-10-11 17:42:50 ~17 min linux/x86_64 📦tgz
✔️ 6ef9f85 #3 2024-10-11 17:44:37 ~19 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.

Overall looks good, but I think we need a better approach instead copying the whole community data (including all the submodels) around

sectionItemCopy.pendingMemberRequests = pendingMemberRequests
sectionItemCopy.declinedMemberRequests = declinedMemberRequests
return sectionItemCopy
}
Copy link
Member

Choose a reason for hiding this comment

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

I don't think there's an easy way; that said, I think this is overkill. For most common properties, I think you can continue using sectionItemModel and only where you need a specific member model, you should pass one of the filtered SFPM models instead of the members

ui/app/AppLayouts/Chat/ChatLayout.qml Outdated Show resolved Hide resolved
ui/app/AppLayouts/Chat/ChatLayout.qml Outdated Show resolved Hide resolved
@jrainville
Copy link
Member Author

@caybro thanks for the review. Indeed, passing the members models when needed was simpler than expected. I thought it was used way more, but it's not that bad and it's way cleaner that way.

ui/app/AppLayouts/Chat/ChatLayout.qml Show resolved Hide resolved
@@ -44,6 +44,7 @@ Item {
required property CurrenciesStore currencyStore
property bool hasAddedContacts: false
property var communityData
property var joinedMembers
Copy link
Member

Choose a reason for hiding this comment

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

You could really just pass the count instead of the whole model :)

@@ -109,7 +113,7 @@ StatusSectionLayout {
id: communityHeader

title: community.name
subTitle: qsTr("%n member(s)", "", community.members.count || 0)
subTitle: qsTr("%n member(s)", "", root.joinedMembers.count || 0)
Copy link
Member

Choose a reason for hiding this comment

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

This is relying on the existence of the count property in the model; better use the ModelCount attached property

Copy link
Member Author

Choose a reason for hiding this comment

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

Dumb question, but what is that? I tried googling and I can't find what you mean.

@@ -959,7 +959,7 @@ QtObject {
id: importControlNodePopup
ImportControlNodePopup {
onClosed: destroy()
onImportControlNode: root.rootStore.promoteSelfToControlNode(community.id)
onImportControlNode: root.rootStore.promoteSelfToControlNode(communityId)
Copy link
Member

Choose a reason for hiding this comment

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

Oh nice catch...

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