Commit Graph

15 Commits

Author SHA1 Message Date
Pascal Precht 07142dc66b fix(CommunityDetailPopup): ensure description wraps properly
Fixes #3052
2021-07-26 13:34:12 -04:00
Anthony Laibe 54570bce6e fix(@desktop/translation): update translation
fixes #2993
2021-07-23 16:35:23 -04:00
Pascal Precht 92d042184a refactor(Communities): use `StatusModal` in `CommunityDetailPopup`
Closes #2892
2021-07-20 08:40:29 -04:00
Sale Djenic 1acbc76cc9 chore(@desktop/general): run translation script
All untranslated properties are translated now using translation scripts.
2021-07-19 12:27:45 -04:00
Jonathan Rainville b213aa230d fix(InviteBubble): adapt invite bubble depending on access level 2021-05-26 15:27:49 -04:00
Jonathan Rainville b45cbe83b7 fix: fix channel list spacing during a search
Fixes #2191
2021-04-13 14:47:35 -04:00
Jonathan Rainville 686cbc7f54 fix: fix communities not showing the letter identicon correctly 2021-03-24 14:20:47 -04:00
Pascal Precht 51c8d86ccc fix(Communities): don't crash on rejoin attempt
Prior to this commit there was a scenario where the application would
crash due a memory bug when attempting to (re)join a community.

The scenario is as follows:

1. User creates or has been invited to community with `ON_REQUEST` permissions
2. User leaves community
3. User decides to rejoin, so she selects the community she's been part
of and hits the "Join" button

At this point Status Desktop would send a new `RequestToJoin` request, as the
community has a corresponding permissions setting.

This would then result in an `already a member` error in status-go, because
status-go checks whether the requestee is already part of the members list of
the community. The error isn't handled inside Status Desktop which causes
a crash because we're trying to access data in memory that doesn't exist.

Why is this happening?

While this might be unexpected, when leaving a community (as done on step 2 of
the mentioned scenario), users don't actually lose membership but simply
"unsubscribe" from all channels in the community in question and their `joined`
flag is set to `false`.

From that point on, re-joininng a community is done by sending a `JoinCommunity`
request (instead of `RequestToJoin`), which will then set the `joined` flag to
`true` and doesn't actually check the membership in the database.

This commit ensures we're calling the right API by checking whether not only
whether the community is needs `ON _REQUEST` permissions, but also whether the
user isn't already a member of it.

Fixes #2017
2021-03-11 10:41:19 -05:00
Pascal Precht 86ea7014f6 fix(Communities): make rejoining communities work
When the communities code was moved into its own view in https://github.com/status-im/status-desktop/commit/b38d1df59
it broke the functionality to join communities again.

Qt complains that the Nim API in use `chatsModel.communities.joinCommunity`
expects two parameters, when it's call with just one.
This is unexpected because the API in question set a default value
for its second parameter.

To make this work again, we have to make sure the `setActive`
parameter is supplied every time we call the API from
within QML.

Also, worth noting that this is not the first time we're running into
a scenario like this.
2021-03-05 13:59:44 -05:00
Jonathan Rainville b38d1df591 refactor: move communities functions to communities view in chat 2021-03-03 16:45:23 -05:00
Jonathan Rainville f9817d4f52 feat: add community requests, permissions, ENS and more 2021-03-03 16:45:23 -05:00
Jonathan Rainville 0e699cac65 chore: run translation scripts 2021-02-18 15:23:58 -05:00
Jonathan Rainville e459d4dbd4 fix: fix PopupModal to not show a footer at all if there is no children 2021-01-13 14:32:35 -05:00
Richard Ramos 2ed3261170 Minor UI changes for communities 2021-01-11 13:57:35 -05:00
Jonathan Rainville 2d3a870f60 wip community invitatations and more 2021-01-11 13:57:35 -05:00