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
In https://github.com/status-im/status-desktop/commit/a90a30af1 we've introduced the functionality to import
communities through the UI via a community private key.
That private key is being validated before it gets imported.
For some reason, validation has been removed in another refactor
later on in https://github.com/status-im/status-desktop/commit/534cb23e1, rendering the import
functionality broken.
This commit re-introduces the `validate()` method to make importing
communities work again.
Prior to this commit, communities without an image would render invisible
in the navigation bar of the application. To avoid this, we're now falling
back to our StatusLetterIdenticon component, which renders the first letter
of the community name with the color of the community.
When a user is part of a community, write access to any channel of
that community is granted. When the permission allows for it, a community's
channel `canPost` property is `true`, which should be relied on to
render the necessary component for writing into a channel.
This commit makes sure community members with proper access get the
chat input rendered so they can write to channels.
Fixes#1985
Very similar to #1986, we're trying to access the `activeCommunity`
property on the `chatsModel` object, which doesn't have such a property
anymore every since we've moved communities into its own view.
This causes errors when trying to create channels.
This commit fixes this bug by ensuring `activeCommunity` is accessed
from `chatsModel.communities` instead.
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.
Turns out in https://github.com/status-im/status-desktop/commit/81bb7fcc6 we've introduced a regression where
leaving a communities isn't possible anymore because we're trying
to call an API that doesn't exist on the `chatsModel`.
This commit fixes it by ensuring the API is called from `chatsModel.communities`.
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
For an unknown reason, when the `chatLogView` ListView uses
a `verticalLayoutDirection: BottomToTop`, it prevents the application
from successfully rendering during login and crashes.
From debugging this, we know that this only happens when the above
condition applies *and* when a `DelegateModel` is used.
The delegate doesn't even need proper data, it application would still
crash.
We found out that the crash can be avoided when another `ListView` exists
in this component (however it's unclear why).
For now this commit adds such a placeholder `ListView` until it
we know more about what's going on.
Pascal Precht
Iuri Matias
Richard Ramos
Jonathan Rainville
ace-smart