- UI simplified, made independent from the backend
- dedicated model created, filtering on the level of model instead of
per delegate
- using ListView instead of mutliple Repeaters
- UI models removed from ProfileSectionStore
Closes: #16675
- use a similar approach as in the DerivationPath popup; ListView
instead of a Repeater
- some smaller fixes & speedups in the SFPM
- reenable the test
Fixes#16683
- use the same approach as status-go to detect the image type, relying
on "magic" type matching instead of looking at the file extension (now
using C++ and QMime*)
- add a little error popup when the user tries to upload an unsupported
image type while creating/editing a community
- expose all the image related properties from the C++ backend instead
of constructing and duplicating them in QML
- cleanup some unused/dead code
Fixes#16668
* perf(contacts): make initial contacts fetching async
Fixes#16509
* fix: don't fetch contact if we don't have it in cache
Fixes#16509
* feat: add a visible loading indicator when the chats are not ready yet
* fix(members): fix member count not updating correctly on join
Fixes#16672
The issue was that the requests to join were not handled in time for when the community update came in, so when we udpated the section, we got both the normal member and the pending member still and they clashed and the pending one came on top, meaning that the joined member was not counted.
On a restart it would fix itself.
To fix it, I reordered the parsing of communities and requests, so that the request is updated first, ie deleted because it is now accepted.
I also fixed the function that handles request to that the state gets updated at all times. Before, it would only get updated if it was not accepted, pending or waiting for address.
Finally, there was a weird scenario where as a TM, I saw myself as pending even if I was joined, so I fixed it by removing duplicates.
* chore(@e2e): remove xfail mark from pin messages test
---------
Co-authored-by: Anastasiya Semenkevich <anastasija.ig@gmail.com>
Fixes#16614
The problem was that I was missing encryption keys for some channels, but since I'm an admin, I still have access, so I could see the member list and it was showing me all members because of a missing condition in the code
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.